Re: [PATCH 07/11] arm64: add basic pointer authentication support

[Yao Qi]

Hi Mark,

On 19/07/17 17:01, Mark Rutland wrote:

+#define HWCAP_APIA   (1 << 16)


Can you rename it to HWCAP_ARM64_APIA or HWCAP_ARM_APIA?  When we
use it in user space, at least in GDB, we usually do this,

#ifndef HWCAP_APIA
#define HWCAP_APIA (1 << 16)
#endif

However, the code use this macro can be compiled on !arm64 host.
If HWCAP_APIA is defined on other !arm64 host and its value is not
(1 << 16), the program "aarch64_hwcap & HWCAP_APIA ? XXX : XXX;" is
wrong, and compiler doesn't complain.

I notice that mips, mn10300, sparc, and s390 define their HWCAP this
way, like HWCAP_SPARC_FLUSH, HWCAP_MIPS_R6, HWCAP_S390_DFP, etc.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH 07/11] arm64: add basic pointer authentication support

[Yao Qi]

Hi Mark,

On 19/07/17 17:01, Mark Rutland wrote:

+#define HWCAP_APIA   (1 << 16)


Can you rename it to HWCAP_ARM64_APIA or HWCAP_ARM_APIA?  When we
use it in user space, at least in GDB, we usually do this,

#ifndef HWCAP_APIA
#define HWCAP_APIA (1 << 16)
#endif

However, the code use this macro can be compiled on !arm64 host.
If HWCAP_APIA is defined on other !arm64 host and its value is not
(1 << 16), the program "aarch64_hwcap & HWCAP_APIA ? XXX : XXX;" is
wrong, and compiler doesn't complain.

I notice that mips, mn10300, sparc, and s390 define their HWCAP this
way, like HWCAP_SPARC_FLUSH, HWCAP_MIPS_R6, HWCAP_S390_DFP, etc.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH 00/11] ARMv8.3 pointer authentication userspace support

[Yao Qi]

On 19/07/17 17:01, Mark Rutland wrote:

If authentication fails, bits are set in the pointer such that it is guaranteed
to cause a fault if used.


How does user space know the fault is caused by authentication fail?
When GDB is debugging a program, and it failed in pointer
authentication, I assume GDB only knows that the program receives signal
SIGSEGV, but how does GDB or user know why does the program get SIGSEGV?
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH 00/11] ARMv8.3 pointer authentication userspace support

[Yao Qi]

On 19/07/17 17:01, Mark Rutland wrote:

If authentication fails, bits are set in the pointer such that it is guaranteed
to cause a fault if used.


How does user space know the fault is caused by authentication fail?
When GDB is debugging a program, and it failed in pointer
authentication, I assume GDB only knows that the program receives signal
SIGSEGV, but how does GDB or user know why does the program get SIGSEGV?
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH 00/11] ARMv8.3 pointer authentication userspace support

[Yao Qi]

On 19/07/17 17:01, Mark Rutland wrote:

* Should the kernel remove PACs when unwinding user stacks?

  This is simple to do, but it's arguably placing a policy in the kernel as to
  what we expect user stacks to look like. Regardless, userspace will have to
  perform this when unwinding with DWARF.


I am not sure what do you mean.  Do you mean stripping a PAC from a
pointer during unwinding, so that user space can unwind the program
without being aware of PAC?  Can kernel remove PAC from all instruction
pointers?  Note that user space debugger may try to unwind in coredump,
so if the contents dumped into coredump including PAC bits, debuggers
still have to be aware of PAC (unless kernel can remove all PAC bits
during coredump too).

IMO, kernel needs to tell the truth to reflect the process/task state
to the user space, and leave the user space to consume.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH 00/11] ARMv8.3 pointer authentication userspace support

[Yao Qi]

On 19/07/17 17:01, Mark Rutland wrote:

* Should the kernel remove PACs when unwinding user stacks?

  This is simple to do, but it's arguably placing a policy in the kernel as to
  what we expect user stacks to look like. Regardless, userspace will have to
  perform this when unwinding with DWARF.


I am not sure what do you mean.  Do you mean stripping a PAC from a
pointer during unwinding, so that user space can unwind the program
without being aware of PAC?  Can kernel remove PAC from all instruction
pointers?  Note that user space debugger may try to unwind in coredump,
so if the contents dumped into coredump including PAC bits, debuggers
still have to be aware of PAC (unless kernel can remove all PAC bits
during coredump too).

IMO, kernel needs to tell the truth to reflect the process/task state
to the user space, and leave the user space to consume.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH 3/4] arm64: Allow hw watchpoint of length 3,5,6 and 7

[Yao Qi]

On Wed, Oct 12, 2016 at 6:58 AM, Pratyush Anand  wrote:
> Since, arm64 can support all offset within a double word limit. Therefore,
> now support other lengths within that range as well.

How does ptracer (like GDB) detect kernel has already supported all byte
address select values?  I suppose ptrace(NT_ARM_HW_WATCH, ) with
len is 3 or 5 fail on current kernel but is of success after your patches
applied.

GDB is aware of the byte address select limitation in kernel, so it always
sets 1,2,4,8 in len in ctrl.  GDB needs to know whether the limitation is still
there or not.

-- 
Yao (齐尧)

Re: [PATCH 3/4] arm64: Allow hw watchpoint of length 3,5,6 and 7

[Yao Qi]

On Wed, Oct 12, 2016 at 6:58 AM, Pratyush Anand  wrote:
> Since, arm64 can support all offset within a double word limit. Therefore,
> now support other lengths within that range as well.

How does ptracer (like GDB) detect kernel has already supported all byte
address select values?  I suppose ptrace(NT_ARM_HW_WATCH, ) with
len is 3 or 5 fail on current kernel but is of success after your patches
applied.

GDB is aware of the byte address select limitation in kernel, so it always
sets 1,2,4,8 in len in ctrl.  GDB needs to know whether the limitation is still
there or not.

-- 
Yao (齐尧)