[v9,3/3] arm64: Relax Documentation/arm64/tagged-pointers.rst
diff mbox series

Message ID 20190821164730.47450-4-catalin.marinas@arm.com
State New
Headers show
Series
  • arm64 tagged address ABI
Related show

Commit Message

Catalin Marinas Aug. 21, 2019, 4:47 p.m. UTC
From: Vincenzo Frascino <vincenzo.frascino@arm.com>

On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
(EL0) to perform memory accesses through 64-bit pointers with a non-zero
top byte. However, such pointers were not allowed at the user-kernel
syscall ABI boundary.

With the Tagged Address ABI patchset, it is now possible to pass tagged
pointers to the syscalls. Relax the requirements described in
tagged-pointers.rst to be compliant with the behaviours guaranteed by
the AArch64 Tagged Address ABI.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Acked-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Co-developed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
 Documentation/arm64/tagged-pointers.rst | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

Comments

Will Deacon Aug. 21, 2019, 5:33 p.m. UTC | #1
On Wed, Aug 21, 2019 at 05:47:30PM +0100, Catalin Marinas wrote:
> From: Vincenzo Frascino <vincenzo.frascino@arm.com>
> 
> On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
> (EL0) to perform memory accesses through 64-bit pointers with a non-zero
> top byte. However, such pointers were not allowed at the user-kernel
> syscall ABI boundary.
> 
> With the Tagged Address ABI patchset, it is now possible to pass tagged
> pointers to the syscalls. Relax the requirements described in
> tagged-pointers.rst to be compliant with the behaviours guaranteed by
> the AArch64 Tagged Address ABI.
> 
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> Acked-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Co-developed-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>  Documentation/arm64/tagged-pointers.rst | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst
> index 2acdec3ebbeb..04f2ba9b779e 100644
> --- a/Documentation/arm64/tagged-pointers.rst
> +++ b/Documentation/arm64/tagged-pointers.rst
> @@ -20,7 +20,9 @@ Passing tagged addresses to the kernel
>  --------------------------------------
>  
>  All interpretation of userspace memory addresses by the kernel assumes
> -an address tag of 0x00.
> +an address tag of 0x00, unless the application enables the AArch64
> +Tagged Address ABI explicitly
> +(Documentation/arm64/tagged-address-abi.rst).
>  
>  This includes, but is not limited to, addresses found in:
>  
> @@ -33,13 +35,15 @@ This includes, but is not limited to, addresses found in:
>   - the frame pointer (x29) and frame records, e.g. when interpreting
>     them to generate a backtrace or call graph.
>  
> -Using non-zero address tags in any of these locations may result in an
> -error code being returned, a (fatal) signal being raised, or other modes
> -of failure.
> +Using non-zero address tags in any of these locations when the
> +userspace application did not enable the AArch64 Tagged Address ABI may
> +result in an error code being returned, a (fatal) signal being raised,
> +or other modes of failure.
>  
> -For these reasons, passing non-zero address tags to the kernel via
> -system calls is forbidden, and using a non-zero address tag for sp is
> -strongly discouraged.
> +For these reasons, when the AArch64 Tagged Address ABI is disabled,
> +passing non-zero address tags to the kernel via system calls is
> +forbidden, and using a non-zero address tag for sp is strongly
> +discouraged.
>  
>  Programs maintaining a frame pointer and frame records that use non-zero
>  address tags may suffer impaired or inaccurate debug and profiling
> @@ -59,6 +63,11 @@ be preserved.
>  The architecture prevents the use of a tagged PC, so the upper byte will
>  be set to a sign-extension of bit 55 on exception return.
>  
> +This behaviour is maintained when the AArch64 Tagged Address ABI is
> +enabled. In addition, with the exceptions above, the kernel will
> +preserve any non-zero tags passed by the user via syscalls and stored in
> +kernel data structures (e.g. ``set_robust_list()``, ``sigaltstack()``).

Hmm. I can see the need to provide this guarantee for things like
set_robust_list(), but the problem is that the statement above is too broad
and isn't strictly true: for example, mmap() doesn't propagate the tag of
its address parameter into the VMA.

So I think we need to nail this down a bit more, but I'm having a really
hard time coming up with some wording :(

Will
Dave Martin Aug. 21, 2019, 6:46 p.m. UTC | #2
On Wed, Aug 21, 2019 at 06:33:53PM +0100, Will Deacon wrote:
> On Wed, Aug 21, 2019 at 05:47:30PM +0100, Catalin Marinas wrote:
> > From: Vincenzo Frascino <vincenzo.frascino@arm.com>
> > 
> > On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
> > (EL0) to perform memory accesses through 64-bit pointers with a non-zero
> > top byte. However, such pointers were not allowed at the user-kernel
> > syscall ABI boundary.
> > 
> > With the Tagged Address ABI patchset, it is now possible to pass tagged
> > pointers to the syscalls. Relax the requirements described in
> > tagged-pointers.rst to be compliant with the behaviours guaranteed by
> > the AArch64 Tagged Address ABI.
> > 
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
> > Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> > Acked-by: Andrey Konovalov <andreyknvl@google.com>
> > Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> > Co-developed-by: Catalin Marinas <catalin.marinas@arm.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> >  Documentation/arm64/tagged-pointers.rst | 23 ++++++++++++++++-------
> >  1 file changed, 16 insertions(+), 7 deletions(-)
> > 
> > diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst
> > index 2acdec3ebbeb..04f2ba9b779e 100644
> > --- a/Documentation/arm64/tagged-pointers.rst
> > +++ b/Documentation/arm64/tagged-pointers.rst
> > @@ -20,7 +20,9 @@ Passing tagged addresses to the kernel
> >  --------------------------------------
> >  
> >  All interpretation of userspace memory addresses by the kernel assumes
> > -an address tag of 0x00.
> > +an address tag of 0x00, unless the application enables the AArch64
> > +Tagged Address ABI explicitly
> > +(Documentation/arm64/tagged-address-abi.rst).
> >  
> >  This includes, but is not limited to, addresses found in:
> >  
> > @@ -33,13 +35,15 @@ This includes, but is not limited to, addresses found in:
> >   - the frame pointer (x29) and frame records, e.g. when interpreting
> >     them to generate a backtrace or call graph.
> >  
> > -Using non-zero address tags in any of these locations may result in an
> > -error code being returned, a (fatal) signal being raised, or other modes
> > -of failure.
> > +Using non-zero address tags in any of these locations when the
> > +userspace application did not enable the AArch64 Tagged Address ABI may
> > +result in an error code being returned, a (fatal) signal being raised,
> > +or other modes of failure.
> >  
> > -For these reasons, passing non-zero address tags to the kernel via
> > -system calls is forbidden, and using a non-zero address tag for sp is
> > -strongly discouraged.
> > +For these reasons, when the AArch64 Tagged Address ABI is disabled,
> > +passing non-zero address tags to the kernel via system calls is
> > +forbidden, and using a non-zero address tag for sp is strongly
> > +discouraged.
> >  
> >  Programs maintaining a frame pointer and frame records that use non-zero
> >  address tags may suffer impaired or inaccurate debug and profiling
> > @@ -59,6 +63,11 @@ be preserved.
> >  The architecture prevents the use of a tagged PC, so the upper byte will
> >  be set to a sign-extension of bit 55 on exception return.
> >  
> > +This behaviour is maintained when the AArch64 Tagged Address ABI is
> > +enabled. In addition, with the exceptions above, the kernel will
> > +preserve any non-zero tags passed by the user via syscalls and stored in
> > +kernel data structures (e.g. ``set_robust_list()``, ``sigaltstack()``).

sigaltstack() is interesting, since we don't support tagged stacks.

Do we keep the ss_sp tag in the kernel, but squash it when delivering
a signal to the alternate stack?

(I can't remember whether this would be compatible with the
architectural tag checking semantics...)

> Hmm. I can see the need to provide this guarantee for things like
> set_robust_list(), but the problem is that the statement above is too broad
> and isn't strictly true: for example, mmap() doesn't propagate the tag of
> its address parameter into the VMA.
> 
> So I think we need to nail this down a bit more, but I'm having a really
> hard time coming up with some wording :(

Time for some creative vagueness?

We can write a statement of our overall intent, along with examples of
a few cases where the tag should and should not be expected to emerge
intact.

There is no foolproof rule, unless we can rewrite history...

Cheers
---Dave
Catalin Marinas Aug. 22, 2019, 3:55 p.m. UTC | #3
On Wed, Aug 21, 2019 at 07:46:51PM +0100, Dave P Martin wrote:
> On Wed, Aug 21, 2019 at 06:33:53PM +0100, Will Deacon wrote:
> > On Wed, Aug 21, 2019 at 05:47:30PM +0100, Catalin Marinas wrote:
> > > @@ -59,6 +63,11 @@ be preserved.
> > >  The architecture prevents the use of a tagged PC, so the upper byte will
> > >  be set to a sign-extension of bit 55 on exception return.
> > >  
> > > +This behaviour is maintained when the AArch64 Tagged Address ABI is
> > > +enabled. In addition, with the exceptions above, the kernel will
> > > +preserve any non-zero tags passed by the user via syscalls and stored in
> > > +kernel data structures (e.g. ``set_robust_list()``, ``sigaltstack()``).
> 
> sigaltstack() is interesting, since we don't support tagged stacks.

We should support tagged SP with the new ABI as they'll be required for
MTE. sigaltstack() and clone() are the two syscalls that come to mind
here.

> Do we keep the ss_sp tag in the kernel, but squash it when delivering
> a signal to the alternate stack?

We don't seem to be doing any untagging, so we just just use whatever
the caller asked for. We may need a small test to confirm.

That said, on_sig_stack() probably needs some untagging as it does user
pointer arithmetics with potentially different tags.

> > Hmm. I can see the need to provide this guarantee for things like
> > set_robust_list(), but the problem is that the statement above is too broad
> > and isn't strictly true: for example, mmap() doesn't propagate the tag of
> > its address parameter into the VMA.
> > 
> > So I think we need to nail this down a bit more, but I'm having a really
> > hard time coming up with some wording :(
> 
> Time for some creative vagueness?
> 
> We can write a statement of our overall intent, along with examples of
> a few cases where the tag should and should not be expected to emerge
> intact.
> 
> There is no foolproof rule, unless we can rewrite history...

I would expect the norm to be the preservation of tags with a few
exceptions. The only ones I think where we won't preserve the tags are
mmap, mremap, brk (apart from the signal stuff already mentioned in the
current tagged-pointers.rst doc).

So I can remove this paragraph altogether and add a note in part 3 of
the tagged-address-abi.rst document that mmap/mremap/brk do not preserve
the tag information.
Dave Martin Aug. 22, 2019, 4:37 p.m. UTC | #4
On Thu, Aug 22, 2019 at 04:55:32PM +0100, Catalin Marinas wrote:
> On Wed, Aug 21, 2019 at 07:46:51PM +0100, Dave P Martin wrote:
> > On Wed, Aug 21, 2019 at 06:33:53PM +0100, Will Deacon wrote:
> > > On Wed, Aug 21, 2019 at 05:47:30PM +0100, Catalin Marinas wrote:
> > > > @@ -59,6 +63,11 @@ be preserved.
> > > >  The architecture prevents the use of a tagged PC, so the upper byte will
> > > >  be set to a sign-extension of bit 55 on exception return.
> > > >  
> > > > +This behaviour is maintained when the AArch64 Tagged Address ABI is
> > > > +enabled. In addition, with the exceptions above, the kernel will
> > > > +preserve any non-zero tags passed by the user via syscalls and stored in
> > > > +kernel data structures (e.g. ``set_robust_list()``, ``sigaltstack()``).
> > 
> > sigaltstack() is interesting, since we don't support tagged stacks.
> 
> We should support tagged SP with the new ABI as they'll be required for
> MTE. sigaltstack() and clone() are the two syscalls that come to mind
> here.
> 
> > Do we keep the ss_sp tag in the kernel, but squash it when delivering
> > a signal to the alternate stack?
> 
> We don't seem to be doing any untagging, so we just just use whatever
> the caller asked for. We may need a small test to confirm.

If we want to support tagged SP, then I guess we shouldn't be squashing
the tag anywhere.  A test for that would be sensible to have.

> That said, on_sig_stack() probably needs some untagging as it does user
> pointer arithmetics with potentially different tags.

Good point.

> > > Hmm. I can see the need to provide this guarantee for things like
> > > set_robust_list(), but the problem is that the statement above is too broad
> > > and isn't strictly true: for example, mmap() doesn't propagate the tag of
> > > its address parameter into the VMA.
> > > 
> > > So I think we need to nail this down a bit more, but I'm having a really
> > > hard time coming up with some wording :(
> > 
> > Time for some creative vagueness?
> > 
> > We can write a statement of our overall intent, along with examples of
> > a few cases where the tag should and should not be expected to emerge
> > intact.
> > 
> > There is no foolproof rule, unless we can rewrite history...
> 
> I would expect the norm to be the preservation of tags with a few
> exceptions. The only ones I think where we won't preserve the tags are
> mmap, mremap, brk (apart from the signal stuff already mentioned in the
> current tagged-pointers.rst doc).
> 
> So I can remove this paragraph altogether and add a note in part 3 of
> the tagged-address-abi.rst document that mmap/mremap/brk do not preserve
> the tag information.

Deleting text is always a good idea ;)

There are other cases like (non-)propagation of the tag to si_addr
when a fault is reported via a signal, but I think we already have
appropriate wording to cover that.

Cheers
---Dave
Catalin Marinas Aug. 23, 2019, 4:19 p.m. UTC | #5
On Thu, Aug 22, 2019 at 05:37:23PM +0100, Dave P Martin wrote:
> On Thu, Aug 22, 2019 at 04:55:32PM +0100, Catalin Marinas wrote:
> > On Wed, Aug 21, 2019 at 07:46:51PM +0100, Dave P Martin wrote:
> > > On Wed, Aug 21, 2019 at 06:33:53PM +0100, Will Deacon wrote:
> > > > On Wed, Aug 21, 2019 at 05:47:30PM +0100, Catalin Marinas wrote:
> > > > > @@ -59,6 +63,11 @@ be preserved.
> > > > >  The architecture prevents the use of a tagged PC, so the upper byte will
> > > > >  be set to a sign-extension of bit 55 on exception return.
> > > > >  
> > > > > +This behaviour is maintained when the AArch64 Tagged Address ABI is
> > > > > +enabled. In addition, with the exceptions above, the kernel will
> > > > > +preserve any non-zero tags passed by the user via syscalls and stored in
> > > > > +kernel data structures (e.g. ``set_robust_list()``, ``sigaltstack()``).
> > > 
> > > sigaltstack() is interesting, since we don't support tagged stacks.
> > 
> > We should support tagged SP with the new ABI as they'll be required for
> > MTE. sigaltstack() and clone() are the two syscalls that come to mind
> > here.
> > 
> > > Do we keep the ss_sp tag in the kernel, but squash it when delivering
> > > a signal to the alternate stack?
> > 
> > We don't seem to be doing any untagging, so we just just use whatever
> > the caller asked for. We may need a small test to confirm.
> 
> If we want to support tagged SP, then I guess we shouldn't be squashing
> the tag anywhere.  A test for that would be sensible to have.

I hacked the sas.c kselftest to use a tagged stack and works fine, the
SP register has a tagged address on the signal handler.

> > > > Hmm. I can see the need to provide this guarantee for things like
> > > > set_robust_list(), but the problem is that the statement above is too broad
> > > > and isn't strictly true: for example, mmap() doesn't propagate the tag of
> > > > its address parameter into the VMA.
> > > > 
> > > > So I think we need to nail this down a bit more, but I'm having a really
> > > > hard time coming up with some wording :(
> > > 
> > > Time for some creative vagueness?
> > > 
> > > We can write a statement of our overall intent, along with examples of
> > > a few cases where the tag should and should not be expected to emerge
> > > intact.
> > > 
> > > There is no foolproof rule, unless we can rewrite history...
> > 
> > I would expect the norm to be the preservation of tags with a few
> > exceptions. The only ones I think where we won't preserve the tags are
> > mmap, mremap, brk (apart from the signal stuff already mentioned in the
> > current tagged-pointers.rst doc).
> > 
> > So I can remove this paragraph altogether and add a note in part 3 of
> > the tagged-address-abi.rst document that mmap/mremap/brk do not preserve
> > the tag information.
> 
> Deleting text is always a good idea ;)

I'm going this route ;).
Dave Martin Aug. 23, 2019, 4:32 p.m. UTC | #6
On Fri, Aug 23, 2019 at 05:19:13PM +0100, Catalin Marinas wrote:
> On Thu, Aug 22, 2019 at 05:37:23PM +0100, Dave P Martin wrote:
> > On Thu, Aug 22, 2019 at 04:55:32PM +0100, Catalin Marinas wrote:
> > > On Wed, Aug 21, 2019 at 07:46:51PM +0100, Dave P Martin wrote:

[...]

> > > > sigaltstack() is interesting, since we don't support tagged stacks.
> > > 
> > > We should support tagged SP with the new ABI as they'll be required for
> > > MTE. sigaltstack() and clone() are the two syscalls that come to mind
> > > here.
> > > 
> > > > Do we keep the ss_sp tag in the kernel, but squash it when delivering
> > > > a signal to the alternate stack?
> > > 
> > > We don't seem to be doing any untagging, so we just just use whatever
> > > the caller asked for. We may need a small test to confirm.
> > 
> > If we want to support tagged SP, then I guess we shouldn't be squashing
> > the tag anywhere.  A test for that would be sensible to have.
> 
> I hacked the sas.c kselftest to use a tagged stack and works fine, the
> SP register has a tagged address on the signal handler.

Cool...

[...]

> > > > There is no foolproof rule, unless we can rewrite history...
> > > 
> > > I would expect the norm to be the preservation of tags with a few
> > > exceptions. The only ones I think where we won't preserve the tags are
> > > mmap, mremap, brk (apart from the signal stuff already mentioned in the
> > > current tagged-pointers.rst doc).
> > > 
> > > So I can remove this paragraph altogether and add a note in part 3 of
> > > the tagged-address-abi.rst document that mmap/mremap/brk do not preserve
> > > the tag information.
> > 
> > Deleting text is always a good idea ;)
> 
> I'm going this route ;).

[reply deleted]

Cheers
---Dave

Patch
diff mbox series

diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst
index 2acdec3ebbeb..04f2ba9b779e 100644
--- a/Documentation/arm64/tagged-pointers.rst
+++ b/Documentation/arm64/tagged-pointers.rst
@@ -20,7 +20,9 @@  Passing tagged addresses to the kernel
 --------------------------------------
 
 All interpretation of userspace memory addresses by the kernel assumes
-an address tag of 0x00.
+an address tag of 0x00, unless the application enables the AArch64
+Tagged Address ABI explicitly
+(Documentation/arm64/tagged-address-abi.rst).
 
 This includes, but is not limited to, addresses found in:
 
@@ -33,13 +35,15 @@  This includes, but is not limited to, addresses found in:
  - the frame pointer (x29) and frame records, e.g. when interpreting
    them to generate a backtrace or call graph.
 
-Using non-zero address tags in any of these locations may result in an
-error code being returned, a (fatal) signal being raised, or other modes
-of failure.
+Using non-zero address tags in any of these locations when the
+userspace application did not enable the AArch64 Tagged Address ABI may
+result in an error code being returned, a (fatal) signal being raised,
+or other modes of failure.
 
-For these reasons, passing non-zero address tags to the kernel via
-system calls is forbidden, and using a non-zero address tag for sp is
-strongly discouraged.
+For these reasons, when the AArch64 Tagged Address ABI is disabled,
+passing non-zero address tags to the kernel via system calls is
+forbidden, and using a non-zero address tag for sp is strongly
+discouraged.
 
 Programs maintaining a frame pointer and frame records that use non-zero
 address tags may suffer impaired or inaccurate debug and profiling
@@ -59,6 +63,11 @@  be preserved.
 The architecture prevents the use of a tagged PC, so the upper byte will
 be set to a sign-extension of bit 55 on exception return.
 
+This behaviour is maintained when the AArch64 Tagged Address ABI is
+enabled. In addition, with the exceptions above, the kernel will
+preserve any non-zero tags passed by the user via syscalls and stored in
+kernel data structures (e.g. ``set_robust_list()``, ``sigaltstack()``).
+
 
 Other considerations
 --------------------