Re: [PATCHv4 06/10] arm64: add basic pointer authentication support
On 5/3/2018 9:20 AM, Mark Rutland wrote:
> This patch adds basic support for pointer authentication, allowing
> userspace to make use of APIAKey. The kernel maintains an APIAKey value
> for each process (shared by all threads within), which is initialised to
> a random value at exec() time.
>
> To describe that address authentication instructions are available, the
> ID_AA64ISAR0.{APA,API} fields are exposed to userspace. A new hwcap,
> APIA, is added to describe that the kernel manages APIAKey.
>
> Instructions using other keys (APIBKey, APDAKey, APDBKey) are disabled,
> and will behave as NOPs. These may be made use of in future patches.
>
> No support is added for the generic key (APGAKey), though this cannot be
> trapped or made to behave as a NOP. Its presence is not advertised with
> a hwcap.
>
> Signed-off-by: Mark Rutland
> Cc: Catalin Marinas
> Cc: Ramana Radhakrishnan
> Cc: Suzuki K Poulose
> Cc: Will Deacon
> ---
Mark, I was able to verify that a buffer overflow exploit results in a segfault
with these PAC patches. When I compile the same binary without
"-msign-return-address=none", I am able to successfully overflow the stack and
execute malicious code.
Thanks
Adam
Tested-by: Adam Wallis
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCHv2 06/12] arm64: add basic pointer authentication support
On 11/27/2017 11:38 AM, Mark Rutland wrote:
> This patch adds basic support for pointer authentication, allowing
> userspace to make use of APIAKey. The kernel maintains an APIAKey value
> for each process (shared by all threads within), which is initialised to
> a random value at exec() time.
>
> To describe that address authentication instructions are available, the
> ID_AA64ISAR0.{APA,API} fields are exposed to userspace. A new hwcap,
> APIA, is added to describe that the kernel manages APIAKey.
>
> Instructions using other keys (APIBKey, APDAKey, APDBKey) are disabled,
> and will behave as NOPs. These may be made use of in future patches.
>
> No support is added for the generic key (APGAKey), though this cannot be
> trapped or made to behave as a NOP. Its presence is not advertised with
> a hwcap.
>
> Signed-off-by: Mark Rutland
> Cc: Catalin Marinas
> Cc: Suzuki K Poulose
> Cc: Will Deacon
> ---
> arch/arm64/include/asm/mmu.h | 5 ++
> arch/arm64/include/asm/mmu_context.h | 25 +-
> arch/arm64/include/asm/pointer_auth.h | 89
> +++
> arch/arm64/include/uapi/asm/hwcap.h | 1 +
> arch/arm64/kernel/cpufeature.c| 17 ++-
> arch/arm64/kernel/cpuinfo.c | 1 +
> 6 files changed, 134 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm64/include/asm/pointer_auth.h
Mark, I was able to verify that a buffer overflow exploit results in a segfault
with these PAC patches. When I compile the same binary without
"-msign-return-address=none", I am able to successfully overflow the stack and
execute malicious code.
Thanks
Adam
Tested-by: Adam Wallis
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH] irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
On 2/1/2018 8:24 AM, Marc Zyngier wrote: > On 01/02/18 12:55, Shanker Donthineni wrote: >> Hi Will, Thanks for your quick reply. >> >> On 02/01/2018 04:33 AM, Will Deacon wrote: >>> Hi Shanker, >>> >>> On Wed, Jan 31, 2018 at 06:03:42PM -0600, Shanker Donthineni wrote: >>>> A DMB instruction can be used to ensure the relative order of only >>>> memory accesses before and after the barrier. Since writes to system >>>> registers are not memory operations, barrier DMB is not sufficient >>>> for observability of memory accesses that occur before ICC_SGI1R_EL1 >>>> writes. >>>> >>>> A DSB instruction ensures that no instructions that appear in program >>>> order after the DSB instruction, can execute until the DSB instruction >>>> has completed. >>>> >>>> Signed-off-by: Shanker Donthineni >>>> --- >>>> drivers/irqchip/irq-gic-v3.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c >>>> index b56c3e2..980ae8e 100644 >>>> --- a/drivers/irqchip/irq-gic-v3.c >>>> +++ b/drivers/irqchip/irq-gic-v3.c >>>> @@ -688,7 +688,7 @@ static void gic_raise_softirq(const struct cpumask >>>> *mask, unsigned int irq) >>>> * Ensure that stores to Normal memory are visible to the >>>> * other CPUs before issuing the IPI. >>>> */ >>>> - smp_wmb(); >>>> + wmb(); >>> >>> I think this is the right thing to do and the smp_wmb() was accidentally >>> pulled in here as a copy-paste from the GICv2 driver where it is sufficient >>> in practice. >>> >>> Did you spot this by code inspection, or did the DMB actually cause >>> observable failures? (trying to figure out whether or not this need to go >>> to -stable). >>> >> >> We've inspected the code because kernel was causing failures in >> scheduler/IPI_RESCHDULE. >> After some time of debugging, we landed in GIC driver and found that the >> issue was due >> to the DMB barrier. > > OK. I've applied this with a cc: stable and Will's Ack. > >> Side note, we're also missing synchronization barriers in GIC driver after >> writing some >> of the ICC_XXX system registers. I'm planning to post those changes for >> comments. >> >> e.g: gic_write_sgi1r(val) and gic_write_eoir(irqnr); > > Thanks, > > M. > Tested-by: Adam Wallis -- Adam Wallis Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 10/21] arm64: entry.S: move SError handling into a C function for future expansion
James On 10/19/2017 10:57 AM, James Morse wrote: [..] > kernel_ventry el1_fiq_invalid // FIQ EL1h > - kernel_ventry el1_error_invalid // Error EL1h > + kernel_ventry el1_error // Error EL1h > > kernel_ventry el0_sync// Synchronous 64-bit > EL0 > kernel_ventry el0_irq // IRQ 64-bit EL0 > kernel_ventry el0_fiq_invalid // FIQ 64-bit EL0 > - kernel_ventry el0_error_invalid // Error 64-bit EL0 > + kernel_ventry el0_error // Error 64-bit EL0 > > #ifdef CONFIG_COMPAT > kernel_ventry el0_sync_compat // Synchronous 32-bit > EL0 > kernel_ventry el0_irq_compat // IRQ 32-bit EL0 > kernel_ventry el0_fiq_invalid_compat // FIQ 32-bit EL0 > - kernel_ventry el0_error_invalid_compat// Error 32-bit EL0 > + kernel_ventry el0_error_compat// Error 32-bit EL0 > #else > kernel_ventry el0_sync_invalid// Synchronous 32-bit > EL0 > kernel_ventry el0_irq_invalid // IRQ 32-bit EL0 > @@ -455,10 +455,6 @@ ENDPROC(el0_error_invalid) > el0_fiq_invalid_compat: > inv_entry 0, BAD_FIQ, 32 > ENDPROC(el0_fiq_invalid_compat) > - > -el0_error_invalid_compat: > - inv_entry 0, BAD_ERROR, 32 > -ENDPROC(el0_error_invalid_compat) > #endif Perhaps I missed something quite obvious, but is there any reason to not also remove el1_error_invalid, since SError handling now jumps to el1_error? > el1_sync_invalid: > @@ -663,6 +659,10 @@ el0_svc_compat: > el0_irq_compat: > kernel_entry 0, 32 > b el0_irq_naked > + > +el0_error_compat: > + kernel_entry 0, 32 > + b el0_error_naked > #endif > > el0_da: > @@ -780,6 +780,28 @@ el0_irq_naked: > b ret_to_user > ENDPROC(el0_irq) > > +el1_error: > + kernel_entry 1 > + mrs x1, esr_el1 > + enable_dbg > + mov x0, sp > + bl do_serror > + kernel_exit 1 > +ENDPROC(el1_error) > + > +el0_error: > + kernel_entry 0 > +el0_error_naked: > + mrs x1, esr_el1 > + enable_dbg > + mov x0, sp > + bl do_serror > + enable_daif > + ct_user_exit > + b ret_to_user > +ENDPROC(el0_error) [..] Thanks Adam -- Adam Wallis Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC 0/9] ARMv8.3 pointer authentication userspace support
h | 5 ++ > arch/arm64/include/asm/mmu_context.h | 25 ++- > arch/arm64/include/asm/pointer_auth.h | 96 > ++ > arch/arm64/include/asm/sysreg.h| 30 > arch/arm64/include/uapi/asm/hwcap.h| 1 + > arch/arm64/include/uapi/asm/ptrace.h | 5 ++ > arch/arm64/kernel/cpufeature.c | 39 ++- > arch/arm64/kernel/cpuinfo.c| 1 + > arch/arm64/kernel/head.S | 19 - > arch/arm64/kernel/ptrace.c | 39 +++ > arch/arm64/kvm/hyp/sysreg-sr.c | 43 > include/asm-generic/mm_hooks.h | 12 > include/uapi/linux/elf.h | 1 + > 21 files changed, 454 insertions(+), 7 deletions(-) > create mode 100644 Documentation/arm64/pointer-authentication.txt > create mode 100644 arch/arm64/include/asm/pointer_auth.h > Tested on Qualcomm platform with ARMV8 architecture (without 8.3 extensions) for backwards compatibility (meaning I did not pass -march=armv8.3-a to GCC; only -msign-return-address=all). The HINT PACIASP/AUTIASP caused no issues and no other issues were encountered. Will test again once a platform is available with 8.3-a extensions. Thanks -- Adam Wallis Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
