From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
To: Dave Hansen <dave.hansen@intel.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Andrey Konovalov <andreyknvl@google.com>,
Kevin Brodsky <Kevin.Brodsky@arm.com>,
Will Deacon <Will.Deacon@arm.com>, nd <nd@arm.com>
Subject: Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
Date: Thu, 8 Aug 2019 09:25:47 +0000 [thread overview]
Message-ID: <48c5f9b3-d253-bede-e755-0aabba2757b5@arm.com> (raw)
In-Reply-To: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com>
On 07/08/2019 21:38, Dave Hansen wrote:
> On 8/7/19 8:53 AM, Catalin Marinas wrote:
>> +- The syscall behaviour is undefined for non valid tagged pointers.
>
> Do you really mean "undefined"? I mean, a bad pointer is a bad pointer.
> Why should it matter if it's a tagged bad pointer or an untagged bad
> pointer?
bad pointers are invalid, but some non-bad pointers are
also invalid if they are tagged (e.g. tagged pointer to
device memory?) those may be valid to dereference in
userspace but don't work across the syscall abi (device
driver does not handle the tag?).
>> +- mmap() addr parameter.
>> +
>> +- mremap() new_address parameter.
>
> Is munmap() missing? Or was there a reason for leaving it out?
the new address in mmap and mremap may not be currently
mapped, other m* functions operate on existing mappings
(munmap, madvise, mprotect, mlock,...)
although by this logic brk (and related PR_SET_MM_*)
should be excluded here too.
>> +- prctl(PR_SET_MM, ``*``, ...) other than arg2 PR_SET_MM_MAP and
>> + PR_SET_MM_MAP_SIZE.
>> +
>> +- prctl(PR_SET_MM, PR_SET_MM_MAP{,_SIZE}, ...) struct prctl_mm_map fields.
>> +
>> +Any attempt to use non-zero tagged pointers will lead to undefined
>> +behaviour.
>
> I wonder if you want to generalize this a bit. I think you're saying
> that parts of the ABI that modify the *layout* of the address space
> never accept tagged pointers.
something like that, but i think this is hard to specify
in a generic way.
WARNING: multiple messages have this Message-ID (diff)
From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
To: Dave Hansen <dave.hansen@intel.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Cc: nd <nd@arm.com>, Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
Andrey Konovalov <andreyknvl@google.com>,
Kevin Brodsky <Kevin.Brodsky@arm.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>
Subject: Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
Date: Thu, 8 Aug 2019 09:25:47 +0000 [thread overview]
Message-ID: <48c5f9b3-d253-bede-e755-0aabba2757b5@arm.com> (raw)
Message-ID: <20190808092547.Q0FXHhGkxwLAp1r2MWOLVxItVdl_yYkO5duo0v_vScM@z> (raw)
In-Reply-To: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com>
On 07/08/2019 21:38, Dave Hansen wrote:
> On 8/7/19 8:53 AM, Catalin Marinas wrote:
>> +- The syscall behaviour is undefined for non valid tagged pointers.
>
> Do you really mean "undefined"? I mean, a bad pointer is a bad pointer.
> Why should it matter if it's a tagged bad pointer or an untagged bad
> pointer?
bad pointers are invalid, but some non-bad pointers are
also invalid if they are tagged (e.g. tagged pointer to
device memory?) those may be valid to dereference in
userspace but don't work across the syscall abi (device
driver does not handle the tag?).
>> +- mmap() addr parameter.
>> +
>> +- mremap() new_address parameter.
>
> Is munmap() missing? Or was there a reason for leaving it out?
the new address in mmap and mremap may not be currently
mapped, other m* functions operate on existing mappings
(munmap, madvise, mprotect, mlock,...)
although by this logic brk (and related PR_SET_MM_*)
should be excluded here too.
>> +- prctl(PR_SET_MM, ``*``, ...) other than arg2 PR_SET_MM_MAP and
>> + PR_SET_MM_MAP_SIZE.
>> +
>> +- prctl(PR_SET_MM, PR_SET_MM_MAP{,_SIZE}, ...) struct prctl_mm_map fields.
>> +
>> +Any attempt to use non-zero tagged pointers will lead to undefined
>> +behaviour.
>
> I wonder if you want to generalize this a bit. I think you're saying
> that parts of the ABI that modify the *layout* of the address space
> never accept tagged pointers.
something like that, but i think this is hard to specify
in a generic way.
next prev parent reply other threads:[~2019-08-08 9:25 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 15:53 [PATCH v7 0/2] arm64 tagged address ABI Catalin Marinas
2019-08-07 15:53 ` Catalin Marinas
2019-08-07 15:53 ` [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst Catalin Marinas
2019-08-07 15:53 ` Catalin Marinas
2019-08-07 20:38 ` Dave Hansen
2019-08-07 20:38 ` Dave Hansen
2019-08-08 9:25 ` Szabolcs Nagy [this message]
2019-08-08 9:25 ` Szabolcs Nagy
2019-08-08 16:20 ` Szabolcs Nagy
2019-08-08 16:20 ` Szabolcs Nagy
2019-08-08 16:27 ` Dave Martin
2019-08-08 16:27 ` Dave Martin
2019-08-08 17:27 ` Catalin Marinas
2019-08-08 17:27 ` Catalin Marinas
2019-08-09 14:10 ` Dave Hansen
2019-08-09 14:10 ` Dave Hansen
2019-08-12 17:36 ` Catalin Marinas
2019-08-12 17:36 ` Catalin Marinas
2019-08-13 11:10 ` Dave Martin
2019-08-13 11:10 ` Dave Martin
2019-08-08 16:30 ` Szabolcs Nagy
2019-08-08 16:30 ` Szabolcs Nagy
2019-08-08 17:04 ` Will Deacon
2019-08-08 17:04 ` Will Deacon
2019-08-12 10:46 ` Andrew Murray
2019-08-12 10:46 ` Andrew Murray
2019-08-12 17:17 ` Catalin Marinas
2019-08-12 17:17 ` Catalin Marinas
2019-08-07 15:53 ` [PATCH v7 2/2] arm64: Relax Documentation/arm64/tagged-pointers.rst Catalin Marinas
2019-08-07 15:53 ` Catalin Marinas
2019-08-08 17:06 ` Will Deacon
2019-08-08 17:06 ` Will Deacon
2019-08-08 9:32 ` [PATCH v7 0/2] arm64 tagged address ABI Szabolcs Nagy
2019-08-08 9:32 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48c5f9b3-d253-bede-e755-0aabba2757b5@arm.com \
--to=szabolcs.nagy@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Kevin.Brodsky@arm.com \
--cc=Vincenzo.Frascino@arm.com \
--cc=Will.Deacon@arm.com \
--cc=andreyknvl@google.com \
--cc=dave.hansen@intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=nd@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox