Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 11/30/15 13:33, Kees Cook wrote: >> >> I think what should do is have a debug option which can be set to "rw", >> "log" or "oops"; the latter should probably be the default. > > Can someone write that patch, and then I will include it in the > series? I haven't touched fault handler code, and

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Mon, Nov 30, 2015 at 1:33 PM, Kees Cook wrote: > On Mon, Nov 30, 2015 at 1:14 PM, H. Peter Anvin wrote: >> On 11/29/15 00:05, Ingo Molnar wrote: >>> >>> * Andy Lutomirski wrote: >>> >> - print a warning and a backtrace, and just mark the page read-write >> so that the machine

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Mon, Nov 30, 2015 at 1:14 PM, H. Peter Anvin wrote: > On 11/29/15 00:05, Ingo Molnar wrote: >> >> * Andy Lutomirski wrote: >> > - print a warning and a backtrace, and just mark the page read-write > so that the machine survives, but we get notified and can fix whatever > broken

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 11/29/15 00:05, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > - print a warning and a backtrace, and just mark the page read-write so that the machine survives, but we get notified and can fix whatever broken code >>> >>> This seems very easy to add. Should I basically

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* Mathias Krause wrote: > On 29 November 2015 at 16:39, Ingo Molnar wrote: > > > > * PaX Team wrote: > > > >> On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > >> > >> > > >> > * PaX Team wrote: > >> > > >> > > i don't see the compile time vs. runtime detection as 'competing' > >> > >

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Mon, Nov 30, 2015 at 1:14 PM, H. Peter Anvin wrote: > On 11/29/15 00:05, Ingo Molnar wrote: >> >> * Andy Lutomirski wrote: >> > - print a warning and a backtrace, and just mark the page read-write > so that the machine survives, but we get

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 11/30/15 13:33, Kees Cook wrote: >> >> I think what should do is have a debug option which can be set to "rw", >> "log" or "oops"; the latter should probably be the default. > > Can someone write that patch, and then I will include it in the > series? I haven't touched fault handler code, and

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Mon, Nov 30, 2015 at 1:33 PM, Kees Cook wrote: > On Mon, Nov 30, 2015 at 1:14 PM, H. Peter Anvin wrote: >> On 11/29/15 00:05, Ingo Molnar wrote: >>> >>> * Andy Lutomirski wrote: >>> >> - print a warning and a backtrace, and

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 11/29/15 00:05, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > - print a warning and a backtrace, and just mark the page read-write so that the machine survives, but we get notified and can fix whatever broken code >>> >>> This seems very easy to add.

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* Mathias Krause wrote: > On 29 November 2015 at 16:39, Ingo Molnar wrote: > > > > * PaX Team wrote: > > > >> On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > >> > >> > > >> > * PaX Team wrote: > >> > > >> > >

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 29 November 2015 at 16:39, Ingo Molnar wrote: > > * PaX Team wrote: > >> On 29 Nov 2015 at 9:08, Ingo Molnar wrote: >> >> > >> > * PaX Team wrote: >> > >> > > i don't see the compile time vs. runtime detection as 'competing' >> > > approaches, >> > > both have their own role. [...] >> > >>

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* PaX Team wrote: > On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > > > > > * PaX Team wrote: > > > > > i don't see the compile time vs. runtime detection as 'competing' > > > approaches, > > > both have their own role. [...] > > > > That's true - but only as long as 'this can be solved in

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > > * PaX Team wrote: > > > i don't see the compile time vs. runtime detection as 'competing' > > approaches, > > both have their own role. [...] > > That's true - but only as long as 'this can be solved in tooling!' is not > used as > an excuse

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* PaX Team wrote: > i don't see the compile time vs. runtime detection as 'competing' approaches, > both have their own role. [...] That's true - but only as long as 'this can be solved in tooling!' is not used as an excuse to oppose the runtime solution and we end up doing neither.

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* Andy Lutomirski wrote: > >> - print a warning and a backtrace, and just mark the page read-write > >> so that the machine survives, but we get notified and can fix whatever > >> broken code > > > > This seems very easy to add. Should I basically reverse the effects of > > mark_rodata_ro(),

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 29 November 2015 at 16:39, Ingo Molnar wrote: > > * PaX Team wrote: > >> On 29 Nov 2015 at 9:08, Ingo Molnar wrote: >> >> > >> > * PaX Team wrote: >> > >> > > i don't see the compile time vs. runtime detection as 'competing' >> >

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* Andy Lutomirski wrote: > >> - print a warning and a backtrace, and just mark the page read-write > >> so that the machine survives, but we get notified and can fix whatever > >> broken code > > > > This seems very easy to add. Should I basically reverse the effects of >

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* PaX Team wrote: > i don't see the compile time vs. runtime detection as 'competing' approaches, > both have their own role. [...] That's true - but only as long as 'this can be solved in tooling!' is not used as an excuse to oppose the runtime solution and we end up

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > > * PaX Team wrote: > > > i don't see the compile time vs. runtime detection as 'competing' > > approaches, > > both have their own role. [...] > > That's true - but only as long as 'this can be solved in tooling!' is not >

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* PaX Team wrote: > On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > > > > > * PaX Team wrote: > > > > > i don't see the compile time vs. runtime detection as 'competing' > > > approaches, > > > both have their own role. [...] > > > > That's true -

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Fri, Nov 27, 2015 at 12:03 PM, Kees Cook wrote: > On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds > wrote: >> On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar wrote: >>> >>> * Andy Lutomirski wrote: >>> > Can you see any fragility in such a technique? After Linus shot down my

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds wrote: > On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar wrote: >> >> * Andy Lutomirski wrote: >> >>> > Can you see any fragility in such a technique? >>> >>> After Linus shot down my rdmsr/rwmsr decoding patch, good luck... >> >> I think that case

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds wrote: > > - just oops and kill the machine, like for any other unhandled kernel > page fault. This is probably what you should have on a server Just to clarify: the "just oops" obviously doesn't have to kill the machine, it depends on what your

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> > Can you see any fragility in such a technique? >> >> After Linus shot down my rdmsr/rwmsr decoding patch, good luck... > > I think that case was entirely different, but I've Cc:-ed Linus to shoot my > idea

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Fri, Nov 27, 2015 at 7:29 AM, PaX Team wrote: > On 27 Nov 2015 at 9:05, Ingo Molnar wrote: > >> * PaX Team wrote: >> >> > On 26 Nov 2015 at 11:42, Ingo Molnar wrote: >> > >> > > * PaX Team wrote: >> > that's actually not the typical case in my experience, but rather these >> > two: >> > >>

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 27 Nov 2015 at 9:05, Ingo Molnar wrote: > * PaX Team wrote: > > > On 26 Nov 2015 at 11:42, Ingo Molnar wrote: > > > > > * PaX Team wrote: > > that's actually not the typical case in my experience, but rather these two: > > > > 1. initial mistake: someone didn't actually check whether the

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* PaX Team wrote: > On 26 Nov 2015 at 11:42, Ingo Molnar wrote: > > > * PaX Team wrote: > > > > > On 26 Nov 2015 at 9:54, Ingo Molnar wrote: > > > > > e.g., imagine that the write was to a function pointer (even an entire > > > ops > > > structure) or a boolean that controls some important

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* Andy Lutomirski wrote: > > Can you see any fragility in such a technique? > > After Linus shot down my rdmsr/rwmsr decoding patch, good luck... I think that case was entirely different, but I've Cc:-ed Linus to shoot my idea down if it's crap. > More seriously, though, I think this is

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds wrote: > > - just oops and kill the machine, like for any other unhandled kernel > page fault. This is probably what you should have on a server Just to clarify: the "just oops" obviously doesn't have to kill the

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Fri, Nov 27, 2015 at 7:29 AM, PaX Team wrote: > On 27 Nov 2015 at 9:05, Ingo Molnar wrote: > >> * PaX Team wrote: >> >> > On 26 Nov 2015 at 11:42, Ingo Molnar wrote: >> > >> > > * PaX Team wrote: >> > that's actually not the

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> > Can you see any fragility in such a technique? >> >> After Linus shot down my rdmsr/rwmsr decoding patch, good luck... > > I think that case was entirely different, but

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds wrote: > On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar wrote: >> >> * Andy Lutomirski wrote: >> >>> > Can you see any fragility in such a technique? >>> >>> After Linus shot

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Fri, Nov 27, 2015 at 12:03 PM, Kees Cook wrote: > On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds > wrote: >> On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar wrote: >>> >>> * Andy Lutomirski wrote:

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 27 Nov 2015 at 9:05, Ingo Molnar wrote: > * PaX Team wrote: > > > On 26 Nov 2015 at 11:42, Ingo Molnar wrote: > > > > > * PaX Team wrote: > > that's actually not the typical case in my experience, but rather these two: > > > > 1. initial

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* PaX Team wrote: > On 26 Nov 2015 at 11:42, Ingo Molnar wrote: > > > * PaX Team wrote: > > > > > On 26 Nov 2015 at 9:54, Ingo Molnar wrote: > > > > > e.g., imagine that the write was to a function pointer (even an entire > > > ops > > >

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* Andy Lutomirski wrote: > > Can you see any fragility in such a technique? > > After Linus shot down my rdmsr/rwmsr decoding patch, good luck... I think that case was entirely different, but I've Cc:-ed Linus to shoot my idea down if it's crap. > More seriously,

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Thu, Nov 26, 2015 at 12:54 AM, Ingo Molnar wrote: > > * PaX Team wrote: > >> On 25 Nov 2015 at 10:13, Mathias Krause wrote: >> >> > I myself had some educating experience seeing my machine triple fault >> > when resuming from a S3 sleep. The root cause was a variable that was >> > annotated

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 26 Nov 2015 at 11:42, Ingo Molnar wrote: > * PaX Team wrote: > > > On 26 Nov 2015 at 9:54, Ingo Molnar wrote: > > > e.g., imagine that the write was to a function pointer (even an entire ops > > structure) or a boolean that controls some important feature for after-init > > code.

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* PaX Team wrote: > On 26 Nov 2015 at 9:54, Ingo Molnar wrote: > > > * PaX Team wrote: > > > > > actually the kernel could silently recover from this given how the page > > > fault > > > handler could easily determine that the fault address fell into the > > > data..read_only section and

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 26 Nov 2015 at 9:54, Ingo Molnar wrote: > * PaX Team wrote: > > > actually the kernel could silently recover from this given how the page > > fault > > handler could easily determine that the fault address fell into the > > data..read_only section and just silently undo the read-only

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* PaX Team wrote: > On 25 Nov 2015 at 10:13, Mathias Krause wrote: > > > I myself had some educating experience seeing my machine triple fault > > when resuming from a S3 sleep. The root cause was a variable that was > > annotated __read_only but that was (unnecessarily) modified during CPU >

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* PaX Team wrote: > On 25 Nov 2015 at 10:13, Mathias Krause wrote: > > > I myself had some educating experience seeing my machine triple fault > > when resuming from a S3 sleep. The root cause was a variable that was > > annotated __read_only but that was (unnecessarily)

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 26 Nov 2015 at 9:54, Ingo Molnar wrote: > * PaX Team wrote: > > > actually the kernel could silently recover from this given how the page > > fault > > handler could easily determine that the fault address fell into the > > data..read_only section and just silently

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

* PaX Team wrote: > On 26 Nov 2015 at 9:54, Ingo Molnar wrote: > > > * PaX Team wrote: > > > > > actually the kernel could silently recover from this given how the page > > > fault > > > handler could easily determine that the fault address fell

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 26 Nov 2015 at 11:42, Ingo Molnar wrote: > * PaX Team wrote: > > > On 26 Nov 2015 at 9:54, Ingo Molnar wrote: > > > e.g., imagine that the write was to a function pointer (even an entire ops > > structure) or a boolean that controls some important feature for

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Thu, Nov 26, 2015 at 12:54 AM, Ingo Molnar wrote: > > * PaX Team wrote: > >> On 25 Nov 2015 at 10:13, Mathias Krause wrote: >> >> > I myself had some educating experience seeing my machine triple fault >> > when resuming from a S3 sleep. The root cause

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 11/25/2015 10:54 AM, Kees Cook wrote: >> >> We should not wait for compile-time support, that doesn't make any >> sense. What would be useful would be a way to override this on the >> command line -- that way, if disabling RO or RO-after-init memory makes >> something work, we have an instant

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Wed, Nov 25, 2015 at 9:31 AM, H. Peter Anvin wrote: > On 11/25/15 01:13, Mathias Krause wrote: >> >> While having that annotation makes perfect sense, not only from a >> security perspective but also from a micro-optimization point of view >> (much like the already existing __read_mostly

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Wed, Nov 25, 2015 at 1:13 AM, Mathias Krause wrote: > On 24 November 2015 at 22:38, Kees Cook wrote: >> Many things are written to only during __init, and never changed >> again. These cannot be made "const" since the compiler will do the wrong >> thing (we do actually need to write to them).

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 11/25/15 01:13, Mathias Krause wrote: > > While having that annotation makes perfect sense, not only from a > security perspective but also from a micro-optimization point of view > (much like the already existing __read_mostly annotation), it has its > drawbacks. Violating the "r/o after

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 25 Nov 2015 at 11:06, Clemens Ladisch wrote: > Mathias Krause wrote: > > [...] > > So, prior extending the usage of the __read_only annotation some > > toolchain support is needed. Maybe a gcc plugin that'll warn/error on > > code that writes to such a variable but is not __init itself. > >

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 25 Nov 2015 at 10:13, Mathias Krause wrote: > I myself had some educating experience seeing my machine triple fault > when resuming from a S3 sleep. The root cause was a variable that was > annotated __read_only but that was (unnecessarily) modified during CPU > bring-up phase. Debugging that

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

Mathias Krause wrote: > [...] > So, prior extending the usage of the __read_only annotation some > toolchain support is needed. Maybe a gcc plugin that'll warn/error on > code that writes to such a variable but is not __init itself. Or mark them as "const". This would require the initialization

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 24 November 2015 at 22:38, Kees Cook wrote: > Many things are written to only during __init, and never changed > again. These cannot be made "const" since the compiler will do the wrong > thing (we do actually need to write to them). Instead, move these items > into a memory region that will

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Wed, Nov 25, 2015 at 1:13 AM, Mathias Krause wrote: > On 24 November 2015 at 22:38, Kees Cook wrote: >> Many things are written to only during __init, and never changed >> again. These cannot be made "const" since the compiler will do the wrong

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 11/25/15 01:13, Mathias Krause wrote: > > While having that annotation makes perfect sense, not only from a > security perspective but also from a micro-optimization point of view > (much like the already existing __read_mostly annotation), it has its > drawbacks. Violating the "r/o after

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 11/25/2015 10:54 AM, Kees Cook wrote: >> >> We should not wait for compile-time support, that doesn't make any >> sense. What would be useful would be a way to override this on the >> command line -- that way, if disabling RO or RO-after-init memory makes >> something work, we have an instant

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On Wed, Nov 25, 2015 at 9:31 AM, H. Peter Anvin wrote: > On 11/25/15 01:13, Mathias Krause wrote: >> >> While having that annotation makes perfect sense, not only from a >> security perspective but also from a micro-optimization point of view >> (much like the already existing

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 24 November 2015 at 22:38, Kees Cook wrote: > Many things are written to only during __init, and never changed > again. These cannot be made "const" since the compiler will do the wrong > thing (we do actually need to write to them). Instead, move these items > into a

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

Mathias Krause wrote: > [...] > So, prior extending the usage of the __read_only annotation some > toolchain support is needed. Maybe a gcc plugin that'll warn/error on > code that writes to such a variable but is not __init itself. Or mark them as "const". This would require the initialization

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 25 Nov 2015 at 11:06, Clemens Ladisch wrote: > Mathias Krause wrote: > > [...] > > So, prior extending the usage of the __read_only annotation some > > toolchain support is needed. Maybe a gcc plugin that'll warn/error on > > code that writes to such a variable but is not __init itself. > >

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

On 25 Nov 2015 at 10:13, Mathias Krause wrote: > I myself had some educating experience seeing my machine triple fault > when resuming from a S3 sleep. The root cause was a variable that was > annotated __read_only but that was (unnecessarily) modified during CPU > bring-up phase. Debugging that