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 i
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 survive
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 co
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 rev
* 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'
> >> > > approaches,
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. [...]
>> >
>> >
* 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 t
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 t
* 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.
Thanks,
* 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(), o
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 rd
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
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 o
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
>
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:
>> >
>> >
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 g
* 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
* 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 mos
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 __
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. ignoring/d
* 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 j
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 prope
* 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
> >
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 d
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 annota
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).
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 init"
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.
>
> Or
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 k
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 c
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 be
One of the easiest ways to protect the kernel from attack is to reduce
the internal attack surface exposed when a "write" flaw is available. By
making as much of the kernel read-only as possible, we reduce the
attack surface.
Many things are written to only during __init, and never changed
again.
32 matches
Mail list logo
