[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <daefeb1f-9553-c26d-0b35-2c4da328aeff@codeaurora.org>
Date: Tue, 22 May 2018 15:06:21 -0400
From: Adam Wallis <awallis@...eaurora.org>
To: Mark Rutland <mark.rutland@....com>, linux-arm-kernel@...ts.infradead.org
Cc: arnd@...db.de, catalin.marinas@....com, cdall@...aro.org,
kvmarm@...ts.cs.columbia.edu, linux-arch@...r.kernel.org,
marc.zyngier@....com, suzuki.poulose@....com, will.deacon@....com,
yao.qi@....com, kernel-hardening@...ts.openwall.com,
linux-kernel@...r.kernel.org
Subject: 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 <mark.rutland@....com>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Suzuki K Poulose <suzuki.poulose@....com>
> Cc: Will Deacon <will.deacon@....com>
> ---
> 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 <awallis@...eaurora.org>
--
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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
