From: lauraa@codeaurora.org (Laura Abbott)
To: linux-arm-kernel@lists.infradead.org
Subject: [ARM ATTEND] catching up on exploit mitigations
Date: Mon, 12 Aug 2013 21:51:59 -0700 [thread overview]
Message-ID: <5209BB6F.2000208@codeaurora.org> (raw)
In-Reply-To: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
On 7/30/2013 12:05 PM, Kees Cook wrote:
> I'd like to propose the topic of catching up to x86 exploit
> mitigations and security features, and potentially identifying
> ARM-unique mitigations/features that could be implemented. Several
> years ago, with Nicolas Pitre doing all the real work, I coordinated
> getting ARM caught up on things like userspace ASLR and
> stack-protector. Recently, based on work by Will Drewry, I ported
> seccomp-bpf to ARM. I'd like to continue this kind of thing, and I
> think it's overdue to examine this area again. A lot of work has
> already been done by grsecurity in this area (see
> http://forums.grsecurity.net/viewtopic.php?f=7&t=3292), so it would be
> good to start there.
>
> While it may expose my current ignorance of low level ARM mechanics,
> I'd like to examine and discuss:
>
> - RO and W^X kernel page table protections (similar to x86's
> DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much
> LPAE and PXN is already handling this, if at all)
>
We've had support for RO/NX on our tree for a while. I'm interested in
attending the summit to share what we've done and to see how much of it
could be mainlined.
> - something like x86's SMEP and SMAP (to deter kernel exploitation
> from userspace)
>
> - vector table protections (needs to be protected like the x86_64
> vsyscall table, RO, etc)
>
> - kernel ASLR (I'm close to having this upstreamable for x86)
>
> - fuzzing (is anyone running trinity or similar on the ARM tree?)
>
> - any other things ... ?
I'd add getting something similar to CONFIG_ARCH_RANDOM for ARM. It
wouldn't be a direct drop in to x86 but we have some usecases for a
framework to hook into the arch_get_random_{int,long}. This is mostly
useful for cases where we need random numbers before the kernel's
entropy source is completely initialized. The last point is a separate
discussion all together.
>
> Thanks,
>
> -Kees
>
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: Laura Abbott <lauraa@codeaurora.org>
To: Kees Cook <keescook@chromium.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
ksummit-2013-discuss@lists.linuxfoundation.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [ARM ATTEND] catching up on exploit mitigations
Date: Mon, 12 Aug 2013 21:51:59 -0700 [thread overview]
Message-ID: <5209BB6F.2000208@codeaurora.org> (raw)
In-Reply-To: <CAGXu5jKv9Vt+Hu0mFYaxggLLDZ46U3KR9MKegUoHH8StXCkBtQ@mail.gmail.com>
On 7/30/2013 12:05 PM, Kees Cook wrote:
> I'd like to propose the topic of catching up to x86 exploit
> mitigations and security features, and potentially identifying
> ARM-unique mitigations/features that could be implemented. Several
> years ago, with Nicolas Pitre doing all the real work, I coordinated
> getting ARM caught up on things like userspace ASLR and
> stack-protector. Recently, based on work by Will Drewry, I ported
> seccomp-bpf to ARM. I'd like to continue this kind of thing, and I
> think it's overdue to examine this area again. A lot of work has
> already been done by grsecurity in this area (see
> http://forums.grsecurity.net/viewtopic.php?f=7&t=3292), so it would be
> good to start there.
>
> While it may expose my current ignorance of low level ARM mechanics,
> I'd like to examine and discuss:
>
> - RO and W^X kernel page table protections (similar to x86's
> DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much
> LPAE and PXN is already handling this, if at all)
>
We've had support for RO/NX on our tree for a while. I'm interested in
attending the summit to share what we've done and to see how much of it
could be mainlined.
> - something like x86's SMEP and SMAP (to deter kernel exploitation
> from userspace)
>
> - vector table protections (needs to be protected like the x86_64
> vsyscall table, RO, etc)
>
> - kernel ASLR (I'm close to having this upstreamable for x86)
>
> - fuzzing (is anyone running trinity or similar on the ARM tree?)
>
> - any other things ... ?
I'd add getting something similar to CONFIG_ARCH_RANDOM for ARM. It
wouldn't be a direct drop in to x86 but we have some usecases for a
framework to hook into the arch_get_random_{int,long}. This is mostly
useful for cases where we need random numbers before the kernel's
entropy source is completely initialized. The last point is a separate
discussion all together.
>
> Thanks,
>
> -Kees
>
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2013-08-13 4:51 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-30 19:05 [ARM ATTEND] catching up on exploit mitigations Kees Cook
2013-07-30 19:05 ` Kees Cook
2013-07-30 22:14 ` [Ksummit-2013-discuss] " Dave Jones
2013-07-30 22:14 ` Dave Jones
2013-07-30 22:28 ` H. Peter Anvin
2013-07-30 22:28 ` H. Peter Anvin
2013-07-31 13:55 ` Jason Cooper
2013-07-31 13:55 ` Jason Cooper
2013-07-30 23:11 ` Aaro Koskinen
2013-07-30 23:11 ` Aaro Koskinen
2013-07-30 23:15 ` Dave Jones
2013-07-30 23:15 ` Dave Jones
2013-07-30 23:33 ` Kees Cook
2013-07-30 23:33 ` Kees Cook
2013-07-31 0:01 ` H. Peter Anvin
2013-07-31 0:01 ` H. Peter Anvin
2013-07-30 23:58 ` Aaro Koskinen
2013-07-30 23:58 ` Aaro Koskinen
2013-07-31 0:04 ` Dave Jones
2013-07-31 0:04 ` Dave Jones
2013-07-31 9:40 ` Russell King - ARM Linux
2013-07-31 9:40 ` Russell King - ARM Linux
2013-07-31 14:24 ` Dave Jones
2013-07-31 14:24 ` Dave Jones
2013-08-01 2:47 ` Olof Johansson
2013-08-01 2:47 ` Olof Johansson
2013-08-01 2:59 ` Dave Jones
2013-08-01 2:59 ` Dave Jones
2013-08-01 16:02 ` Vince Weaver
2013-08-01 16:02 ` Vince Weaver
2013-08-21 15:26 ` Russell King - ARM Linux
2013-08-21 15:26 ` Russell King - ARM Linux
2013-08-21 15:43 ` Dave Jones
2013-08-21 15:43 ` Dave Jones
2013-08-21 15:56 ` Russell King - ARM Linux
2013-08-21 15:56 ` Russell King - ARM Linux
2013-08-01 9:13 ` Dan Carpenter
2013-08-01 9:13 ` Dan Carpenter
2013-08-01 19:05 ` Dave Jones
2013-08-01 19:05 ` Dave Jones
2013-08-01 19:16 ` Dan Carpenter
2013-08-01 19:16 ` Dan Carpenter
2013-08-01 19:26 ` Julia Lawall
2013-08-01 19:26 ` Julia Lawall
2013-08-03 0:03 ` Russell King - ARM Linux
2013-08-06 21:44 ` Kees Cook
2013-08-13 4:51 ` Laura Abbott [this message]
2013-08-13 4:51 ` Laura Abbott
2013-08-26 19:56 ` Mark Brown
2013-08-26 19:56 ` Mark Brown
2013-08-27 2:09 ` Laura Abbott
2013-08-27 2:09 ` Laura Abbott
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=5209BB6F.2000208@codeaurora.org \
--to=lauraa@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.