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)
- 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 ... ?
Thanks,
-Kees
--
Kees Cook
Chrome OS Security
On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
> - fuzzing (is anyone running trinity or similar on the ARM tree?)
Someone was kind enough to send me an arm chromebook, so I tried this just
last week (albeit, on the 3.4 kernel it shipped with). The results make
me think the answer is a resounding 'no'.
I don't have time to build more recent kernels on it, but I wouldn't
be surprised to find that things aren't much better (If they are, someone
is seriously sucking at backporting stuff to stable).
There's no ARM64 support yet in trinity, though it'd be easy to add for
someone with hardware. Again, wouldn't be surprised at all to learn there
are bugs there (It's been true of every new arch ported to so far).
On the subject of trinity, I've been hesitant about proposing a slot
at k-s this year, though if there's interest I'm always happy to talk
about it, and get feedback for new places it could go..
Dave
On 07/30/2013 03:14 PM, Dave Jones wrote:
>
> On the subject of trinity, I've been hesitant about proposing a slot
> at k-s this year, though if there's interest I'm always happy to talk
> about it, and get feedback for new places it could go..
>
I'd certainly be interested, no matter which forum.
-hpa
Hi,
On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
> On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
> > - fuzzing (is anyone running trinity or similar on the ARM tree?)
>
> Someone was kind enough to send me an arm chromebook, so I tried this just
> last week (albeit, on the 3.4 kernel it shipped with). The results make
> me think the answer is a resounding 'no'.
Shouldn't you run trinity only under QEMU or similar virtual
environment? Don't know about chromebook, but on some of my ARM boards
a misbehaving kernel could at least in theory brick the board...
A.
On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
> Hi,
>
> On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
> > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
> > > - fuzzing (is anyone running trinity or similar on the ARM tree?)
> >
> > Someone was kind enough to send me an arm chromebook, so I tried this just
> > last week (albeit, on the 3.4 kernel it shipped with). The results make
> > me think the answer is a resounding 'no'.
>
> Shouldn't you run trinity only under QEMU or similar virtual
> environment? Don't know about chromebook, but on some of my ARM boards
> a misbehaving kernel could at least in theory brick the board...
I like to live dangerously. Don't imitate everything you see on TV,
or read about on lkml.
More seriously, that's true if you're running trinity as root, which
yes, I usually advise people only do in qemu etc.
If you're running it as a regular user and you can brick the board,
you might have bigger problems.
Dave
On Tue, Jul 30, 2013 at 4:15 PM, Dave Jones <[email protected]> wrote:
> On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
> > Hi,
> >
> > On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
> > > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
> > > > - fuzzing (is anyone running trinity or similar on the ARM tree?)
> > >
> > > Someone was kind enough to send me an arm chromebook, so I tried this just
> > > last week (albeit, on the 3.4 kernel it shipped with). The results make
> > > me think the answer is a resounding 'no'.
> >
> > Shouldn't you run trinity only under QEMU or similar virtual
> > environment? Don't know about chromebook, but on some of my ARM boards
> > a misbehaving kernel could at least in theory brick the board...
>
> I like to live dangerously. Don't imitate everything you see on TV,
> or read about on lkml.
>
> More seriously, that's true if you're running trinity as root, which
> yes, I usually advise people only do in qemu etc.
>
> If you're running it as a regular user and you can brick the board,
> you might have bigger problems.
Exactly, and finding those problems tends to be worth the hardware hassle. :)
-Kees
--
Kees Cook
Chrome OS Security
Hi,
On Tue, Jul 30, 2013 at 07:15:33PM -0400, Dave Jones wrote:
> On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
> > On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
> > > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
> > > > - fuzzing (is anyone running trinity or similar on the ARM tree?)
> > >
> > > Someone was kind enough to send me an arm chromebook, so I tried this just
> > > last week (albeit, on the 3.4 kernel it shipped with). The results make
> > > me think the answer is a resounding 'no'.
> >
> > Shouldn't you run trinity only under QEMU or similar virtual
> > environment? Don't know about chromebook, but on some of my ARM boards
> > a misbehaving kernel could at least in theory brick the board...
>
> I like to live dangerously. Don't imitate everything you see on TV,
> or read about on lkml.
Sadly I have no TV. :)
Anyway, I think it would be interesting to learn about arch-specific
bugs discovered with trinity. Quickly thinking, the results should be
mostly same regardless of the architecture since the code being tested
is generic especially when running as a regular user. But of course
there are 32/64-bit and big-endian/little-endian and such differences,
and maybe some permission bugs (likely in vendor kernels).
A.
On 07/30/2013 04:33 PM, Kees Cook wrote:
>>
>> If you're running it as a regular user and you can brick the board,
>> you might have bigger problems.
>
> Exactly, and finding those problems tends to be worth the hardware hassle. :)
>
Even as root the number of things allowed to brick the hardware is quite
small. Call it destructive testing.
-hpa
On Wed, Jul 31, 2013 at 02:58:34AM +0300, Aaro Koskinen wrote:
> Anyway, I think it would be interesting to learn about arch-specific
> bugs discovered with trinity. Quickly thinking, the results should be
> mostly same regardless of the architecture since the code being tested
> is generic especially when running as a regular user. But of course
> there are 32/64-bit and big-endian/little-endian and such differences,
> and maybe some permission bugs (likely in vendor kernels).
To use ARM as an example, the bugs I've seen have mostly been in arch specific
code that does things like page-table manipulation. The chromebook bugs I
was hitting for eg were various kinds of PTE corruption warnings.
ISTR the ia64 & sparc64 bugs it discovered long ago were also due to
things like missing cache flushes, as well as trivial fence-post errors.
Dave
On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
> To use ARM as an example, the bugs I've seen have mostly been in arch specific
> code that does things like page-table manipulation. The chromebook bugs I
> was hitting for eg were various kinds of PTE corruption warnings.
Hmm, really? Did you reported these bugs? I'm not aware of mainline
having any changes related to bug reports on PTEs on ARM.
On Tue, Jul 30, 2013 at 03:28:59PM -0700, H. Peter Anvin wrote:
> On 07/30/2013 03:14 PM, Dave Jones wrote:
> >
> > On the subject of trinity, I've been hesitant about proposing a slot
> > at k-s this year, though if there's interest I'm always happy to talk
> > about it, and get feedback for new places it could go..
> >
>
> I'd certainly be interested, no matter which forum.
I would be as well.
thx,
Jason.
On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
> > To use ARM as an example, the bugs I've seen have mostly been in arch specific
> > code that does things like page-table manipulation. The chromebook bugs I
> > was hitting for eg were various kinds of PTE corruption warnings.
>
> Hmm, really? Did you reported these bugs? I'm not aware of mainline
> having any changes related to bug reports on PTEs on ARM.
I wasn't sure if it was a googleism, or happens on mainline, so no.
Dave
On Wed, Jul 31, 2013 at 7:24 AM, Dave Jones <[email protected]> wrote:
> On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
> > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
> > > code that does things like page-table manipulation. The chromebook bugs I
> > > was hitting for eg were various kinds of PTE corruption warnings.
> >
> > Hmm, really? Did you reported these bugs? I'm not aware of mainline
> > having any changes related to bug reports on PTEs on ARM.
>
> I wasn't sure if it was a googleism, or happens on mainline, so no.
We'd definitely be interested in hearing about what you've found. The
3.4 kernel has a lot of out-of-tree code for exynos, we've reduced it
quite a bit on the upcoming 3.8 one but it needs a bit more baking.
As of 3.10, it's not actually hard to run a mainline kernel on the
chromebook, but you have limited functionality (no wifi, no USB3, no
accellerated graphics). Easiest is to do it by booting from SD card.
See instructions at
http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook.
How long would a useful run of trinity take? I've got an
autobuilder/autobooter setup here with a cross-section of current ARM
hardware (7 platforms and counting) that I mostly do boot testing on,
and I should add a smallish suite of testcases to the same. Trinity
would be a good candidate for that.
-Olof
On Wed, Jul 31, 2013 at 07:47:30PM -0700, Olof Johansson wrote:
> > > Hmm, really? Did you reported these bugs? I'm not aware of mainline
> > > having any changes related to bug reports on PTEs on ARM.
> >
> > I wasn't sure if it was a googleism, or happens on mainline, so no.
>
> As of 3.10, it's not actually hard to run a mainline kernel on the
> chromebook, but you have limited functionality (no wifi, no USB3, no
> accellerated graphics). Easiest is to do it by booting from SD card.
> See instructions at
> http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook.
Yeah, that's how I got Fedora running on it (I think the people who did the
Fedora spin for the chromebook chose the google kernel for exactly
the reasons you mention above). It felt a little sluggish for a native
kernel build though, and I'm not setup for cross-building so I stuck with
the 3.4 build.
> How long would a useful run of trinity take?
It blew up in a minute or so of runtime when I tried last week.
> I've got an autobuilder/autobooter setup here with a cross-section of current ARM
> hardware (7 platforms and counting) that I mostly do boot testing on,
> and I should add a smallish suite of testcases to the same. Trinity
> would be a good candidate for that.
Feel free to mail me off-list if I can do anything to help out, though
hopefully things should build & run 'out of the box'. You shouldn't
need any special command line args (though you might get inspiration
for ideas from the scripts/test-* harnesses)
Dave
I was just reading http://faultlinux.lip6.fr/ which says that in
2011 the static checker fault rate in arch/ and fs/ was worse than
in drivers/. I suspect that there are some security vulnerabilities
there.
regards,
dan carpenter
On Wed, 31 Jul 2013, Dave Jones wrote:
> On Wed, Jul 31, 2013 at 07:47:30PM -0700, Olof Johansson wrote:
> > How long would a useful run of trinity take?
>
> It blew up in a minute or so of runtime when I tried last week.
I also have a chromebook running 3.4 and it is trivially easy to crash it
with some simple perf_event tests I have (not the fuzzer, but just the
regular validation tests that test counter overflow).
Like Dave, I didn't bother reporting the problem because I figured 3.4 was
too old for anyone to care about and it was a struggle getting any
distro/kernel installed at all on the system let alone trying to boot
something close to current mainline on it.
Vince
On Thu, Aug 01, 2013 at 12:13:22PM +0300, Dan Carpenter wrote:
> I was just reading http://faultlinux.lip6.fr/ which says that in
> 2011 the static checker fault rate in arch/ and fs/ was worse than
> in drivers/
I've been working on getting more regular builds in coverity, so we can
get more meaningful statistics on things like "what area is getting worse".
Of the current bugs I've categorised so far, here's the breakdown for 3.11-rc3
in terms of highest bug counts.
Drivers/net/wireless: 659
Drivers/ [1] : 600
Drivers/staging: 449
Drivers/scsi: 409
Drivers/net: 350
Net/[2] : 297
Drivers/media: 286
Sound: 220
Drivers/GPU: 217
That's the top categories for the whole kernel.
That wireless was top of the list was the least shocking thing to me,
based on what we get reported to Fedora bugzilla. That it found more
bugs there than in staging was amusing though. The good news is that
wireless also takes the top slot for 'resolved' issues.
The paper above talks about 'arch' but doesn't indicate if it's counting
all arches, or just the one they run the tests on. (Coverity only covers x86,
so arch/ shows up in 10th place there).
FS doesn't show up on the list until 14th place, where there's a another
catchall category like [1][2]. The first actual fs category with the most
bugs is btrfs at 16th place, with 68 outstanding reports.
There's a lot of work to do picking through their database, including writing
modelling functions to reduce false positives. But, I'm on it.
I'll write up something a bit more in-depth later.
Dave
[1] This is everything that doesn't match one of the more specific drivers category,
of which there's those mentioned above, plus about a dozen others.
[2] This is everything in net/ except for ipv4/ipv6/sctp, so all the weirdo protocols basically.
On Thu, Aug 01, 2013 at 03:05:56PM -0400, Dave Jones wrote:
> On Thu, Aug 01, 2013 at 12:13:22PM +0300, Dan Carpenter wrote:
> > I was just reading http://faultlinux.lip6.fr/ which says that in
> > 2011 the static checker fault rate in arch/ and fs/ was worse than
> > in drivers/
>
> I've been working on getting more regular builds in coverity, so we can
> get more meaningful statistics on things like "what area is getting worse".
>
> Of the current bugs I've categorised so far, here's the breakdown for 3.11-rc3
> in terms of highest bug counts.
>
> Drivers/net/wireless: 659
> Drivers/ [1] : 600
> Drivers/staging: 449
> Drivers/scsi: 409
> Drivers/net: 350
> Net/[2] : 297
> Drivers/media: 286
> Sound: 220
> Drivers/GPU: 217
>
> That's the top categories for the whole kernel.
>
> That wireless was top of the list was the least shocking thing to me,
> based on what we get reported to Fedora bugzilla. That it found more
> bugs there than in staging was amusing though. The good news is that
> wireless also takes the top slot for 'resolved' issues.
>
> The paper above talks about 'arch' but doesn't indicate if it's counting
> all arches, or just the one they run the tests on. (Coverity only covers x86,
> so arch/ shows up in 10th place there).
It's Coccinelle, so my guess is they ran it on all the .c files.
regards,
dan carpenter
On Thu, 1 Aug 2013, Dan Carpenter wrote:
> On Thu, Aug 01, 2013 at 03:05:56PM -0400, Dave Jones wrote:
> > On Thu, Aug 01, 2013 at 12:13:22PM +0300, Dan Carpenter wrote:
> > > I was just reading http://faultlinux.lip6.fr/ which says that in
> > > 2011 the static checker fault rate in arch/ and fs/ was worse than
> > > in drivers/
> >
> > I've been working on getting more regular builds in coverity, so we can
> > get more meaningful statistics on things like "what area is getting worse".
> >
> > Of the current bugs I've categorised so far, here's the breakdown for 3.11-rc3
> > in terms of highest bug counts.
> >
> > Drivers/net/wireless: 659
> > Drivers/ [1] : 600
> > Drivers/staging: 449
> > Drivers/scsi: 409
> > Drivers/net: 350
> > Net/[2] : 297
> > Drivers/media: 286
> > Sound: 220
> > Drivers/GPU: 217
> >
> > That's the top categories for the whole kernel.
> >
> > That wireless was top of the list was the least shocking thing to me,
> > based on what we get reported to Fedora bugzilla. That it found more
> > bugs there than in staging was amusing though. The good news is that
> > wireless also takes the top slot for 'resolved' issues.
> >
> > The paper above talks about 'arch' but doesn't indicate if it's counting
> > all arches, or just the one they run the tests on. (Coverity only covers x86,
> > so arch/ shows up in 10th place there).
>
> It's Coccinelle, so my guess is they ran it on all the .c files.
Coccinelle runs on all C files. The rates in the paper are relative to
what are referred to as notes, ie the number of potential bug sites.
For example, code that does not use kmalloc is not likely to contain
missing kfrees.
julia
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
On Wed, Jul 31, 2013 at 10:24:30AM -0400, Dave Jones wrote:
> On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
> > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
> > > code that does things like page-table manipulation. The chromebook bugs I
> > > was hitting for eg were various kinds of PTE corruption warnings.
> >
> > Hmm, really? Did you reported these bugs? I'm not aware of mainline
> > having any changes related to bug reports on PTEs on ARM.
>
> I wasn't sure if it was a googleism, or happens on mainline, so no.
I've been running several iterations of it for a while (== up to 10 minutes
run time - which is normally about how long it takes to find the rather-too-
exposed kmalloc in sys_oabi_epoll_wait) and so far have seen no sign of any
page table corruption.
Maybe you can give some ideas as to how you were running it? Was it
running as root or as a normal user? Were there any nonstandard platform
specific devices in /dev which that user could access - such as graphics
or video decoder devices which could be exposing big holes?
On Wed, Aug 21, 2013 at 04:26:14PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 31, 2013 at 10:24:30AM -0400, Dave Jones wrote:
> > On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
> > > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
> > > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
> > > > code that does things like page-table manipulation. The chromebook bugs I
> > > > was hitting for eg were various kinds of PTE corruption warnings.
> > >
> > > Hmm, really? Did you reported these bugs? I'm not aware of mainline
> > > having any changes related to bug reports on PTEs on ARM.
> >
> > I wasn't sure if it was a googleism, or happens on mainline, so no.
>
> I've been running several iterations of it for a while (== up to 10 minutes
> run time - which is normally about how long it takes to find the rather-too-
> exposed kmalloc in sys_oabi_epoll_wait) and so far have seen no sign of any
> page table corruption.
awesome. Guess it was a google specific issue then.
(Or something that got fixed post 3.4)
> Maybe you can give some ideas as to how you were running it? Was it
> running as root or as a normal user?
yeah, unpriv'd user.
> Were there any nonstandard platform
> specific devices in /dev which that user could access - such as graphics
> or video decoder devices which could be exposing big holes?
I'm not sure what google patched into that kernel altogether, so who knows..
Dave
On Wed, Aug 21, 2013 at 11:43:55AM -0400, Dave Jones wrote:
> On Wed, Aug 21, 2013 at 04:26:14PM +0100, Russell King - ARM Linux wrote:
> > I've been running several iterations of it for a while (== up to 10 minutes
> > run time - which is normally about how long it takes to find the rather-too-
> > exposed kmalloc in sys_oabi_epoll_wait) and so far have seen no sign of any
> > page table corruption.
>
> awesome. Guess it was a google specific issue then.
> (Or something that got fixed post 3.4)
It's been running on this run for 38 minutes so far (having put a
__GFP_NOWARN stopper in that kmalloc - which I think there needs to be
a better solution.)
What I have noticed is during the initialisation of the fd[] array, it
sometimes hangs on a futex. Killing trinity, removing all the files
and restarting it seems to sort the problem out. I'm not sure what's
doing that - any ideas? I couldn't find any evidence of another trinity
thread doing anything with futexes.
> > Were there any nonstandard platform
> > specific devices in /dev which that user could access - such as graphics
> > or video decoder devices which could be exposing big holes?
>
> I'm not sure what google patched into that kernel altogether, so who knows..
Unfortunately, it seems to be rather common if there's hardware GPU or
video codecs to expose physical addresses to userspace which get passed
around in closed source libraries and ultimately to GPU/video hardware.
I would not be surprised if trinity was finding that and finding some
way to get something to poke randomly in kernel memory.
It seems also that the normal approach is to expose the device nodes in
/dev to the world, effectively handing any userspace program the ability
to:
(a) a way to allocate from a pool of memory, and get its physical address
(b) to be able to pass a physical address to hardware for DMA type operations
(c) to initiate DMA on that hardware
This is why closed source GPU/video stuff is Bad News(tm) for security.
I'd strongly suggest keeping such platforms well away from any data
anyone cares about keeping private and keeping them well isolated. :)
On Mon, Aug 12, 2013 at 09:51:59PM -0700, Laura Abbott wrote:
> On 7/30/2013 12:05 PM, Kees Cook wrote:
> >- 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.
Is that related to the code that Google have in their tree?
On 8/26/2013 12:56 PM, Mark Brown wrote:
> On Mon, Aug 12, 2013 at 09:51:59PM -0700, Laura Abbott wrote:
>> On 7/30/2013 12:05 PM, Kees Cook wrote:
>
>>> - 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.
>
> Is that related to the code that Google have in their tree?
It's 'related' in that it covers some of the same use cases but the two
were developed independently as far as I know.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation