Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1276768 > unrolled thread
| Started by | Kees Cook <keescook@chromium.org> |
|---|---|
| First post | 2015-11-24 22:40 +0100 |
| Last post | 2015-11-25 20:10 +0100 |
| Articles | 16 on this page of 36 — 9 participants |
Back to article view | Back to linux.kernel
[PATCH 0/2] introduce post-init read-only memory Kees Cook <keescook@chromium.org> - 2015-11-24 22:40 +0100
[PATCH 1/2] x86: introduce post-init read-only memory Kees Cook <keescook@chromium.org> - 2015-11-24 22:40 +0100
Re: [PATCH 1/2] x86: introduce post-init read-only memory Andy Lutomirski <luto@amacapital.net> - 2015-11-25 01:40 +0100
Re: [PATCH 1/2] x86: introduce post-init read-only memory Kees Cook <keescook@chromium.org> - 2015-11-25 01:50 +0100
Re: [kernel-hardening] Re: [PATCH 1/2] x86: introduce post-init read-only memory Michael Ellerman <mpe@ellerman.id.au> - 2015-11-25 02:00 +0100
Re: [kernel-hardening] Re: [PATCH 1/2] x86: introduce post-init read-only memory Kees Cook <keescook@chromium.org> - 2015-11-25 16:10 +0100
Re: [kernel-hardening] Re: [PATCH 1/2] x86: introduce post-init read-only memory Michael Ellerman <mpe@ellerman.id.au> - 2015-11-26 00:10 +0100
Re: [kernel-hardening] Re: [PATCH 1/2] x86: introduce post-init read-only memory Kees Cook <keescook@chromium.org> - 2015-11-26 00:40 +0100
[PATCH 2/2] x86, vdso: mark vDSO read-only after init Kees Cook <keescook@chromium.org> - 2015-11-24 22:50 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Mathias Krause <minipli@googlemail.com> - 2015-11-25 10:20 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Clemens Ladisch <clemens@ladisch.de> - 2015-11-25 11:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory "PaX Team" <pageexec@freemail.hu> - 2015-11-25 12:20 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory "PaX Team" <pageexec@freemail.hu> - 2015-11-25 12:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Ingo Molnar <mingo@kernel.org> - 2015-11-26 10:00 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory "PaX Team" <pageexec@freemail.hu> - 2015-11-26 11:00 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Ingo Molnar <mingo@kernel.org> - 2015-11-26 11:50 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory "PaX Team" <pageexec@freemail.hu> - 2015-11-26 13:20 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Ingo Molnar <mingo@kernel.org> - 2015-11-27 09:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory "PaX Team" <pageexec@freemail.hu> - 2015-11-27 16:40 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Andy Lutomirski <luto@amacapital.net> - 2015-11-27 17:40 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Ingo Molnar <mingo@kernel.org> - 2015-11-29 09:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory "PaX Team" <pageexec@freemail.hu> - 2015-11-29 12:20 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Ingo Molnar <mingo@kernel.org> - 2015-11-29 16:40 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Mathias Krause <minipli@googlemail.com> - 2015-11-29 19:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Ingo Molnar <mingo@kernel.org> - 2015-11-30 09:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Andy Lutomirski <luto@amacapital.net> - 2015-11-26 17:20 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Ingo Molnar <mingo@kernel.org> - 2015-11-27 09:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Linus Torvalds <torvalds@linux-foundation.org> - 2015-11-27 19:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Linus Torvalds <torvalds@linux-foundation.org> - 2015-11-27 19:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Kees Cook <keescook@chromium.org> - 2015-11-27 21:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Andy Lutomirski <luto@amacapital.net> - 2015-11-27 21:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Ingo Molnar <mingo@kernel.org> - 2015-11-29 09:10 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Kees Cook <keescook@chromium.org> - 2015-11-25 18:30 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory "H. Peter Anvin" <hpa@zytor.com> - 2015-11-25 18:40 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory Kees Cook <keescook@chromium.org> - 2015-11-25 20:00 +0100
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory "H. Peter Anvin" <hpa@zytor.com> - 2015-11-25 20:10 +0100
Page 2 of 2 — ← Prev page 1 [2]
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Date | 2015-11-29 09:10 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qA5dv-3H7-5@gated-at.bofh.it> |
| In reply to | #1278849 |
* PaX Team <pageexec@freemail.hu> 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, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "PaX Team" <pageexec@freemail.hu> |
|---|---|
| Date | 2015-11-29 12:20 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qA8bn-5sO-1@gated-at.bofh.it> |
| In reply to | #1279293 |
On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > > * PaX Team <pageexec@freemail.hu> 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. actually, i already voiced my opinion elsewhere in the constify thread on the kernel hardening list that adding/using __read_only is somewhat premature without also adding the compile time verification part (as part of the constify plugin for example). right now its use on the embedded vdso image is simple and easy to verify but once people begin to add it to variables that the compiler knows and cares about (say, the ops structures) then things can become fragile without compile checking. so yes, i'd also advise to get such tooling in *before* more __read_only usage is added. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Date | 2015-11-29 16:40 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qAcf0-7SQ-15@gated-at.bofh.it> |
| In reply to | #1279316 |
* PaX Team <pageexec@freemail.hu> wrote: > On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > > > > > * PaX Team <pageexec@freemail.hu> 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. > > actually, i already voiced my opinion elsewhere in the constify thread on the > kernel hardening list that adding/using __read_only is somewhat premature > without also adding the compile time verification part (as part of the constify > plugin for example). right now its use on the embedded vdso image is simple and > easy to verify but once people begin to add it to variables that the compiler > knows and cares about (say, the ops structures) then things can become fragile > without compile checking. so yes, i'd also advise to get such tooling in > *before* more __read_only usage is added. I think you are mistaken there: if we add the page fault fixup to make sure we don't crash if a read-only variable is accessed, then we'll have most of the benefits of read-only mappings and no fragility - without having to wait for tooling. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Mathias Krause <minipli@googlemail.com> |
|---|---|
| Date | 2015-11-29 19:10 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qAeAa-13W-21@gated-at.bofh.it> |
| In reply to | #1279364 |
On 29 November 2015 at 16:39, Ingo Molnar <mingo@kernel.org> wrote: > > * PaX Team <pageexec@freemail.hu> wrote: > >> On 29 Nov 2015 at 9:08, Ingo Molnar wrote: >> >> > >> > * PaX Team <pageexec@freemail.hu> 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. >> >> actually, i already voiced my opinion elsewhere in the constify thread on the >> kernel hardening list that adding/using __read_only is somewhat premature >> without also adding the compile time verification part (as part of the constify >> plugin for example). right now its use on the embedded vdso image is simple and >> easy to verify but once people begin to add it to variables that the compiler >> knows and cares about (say, the ops structures) then things can become fragile >> without compile checking. so yes, i'd also advise to get such tooling in >> *before* more __read_only usage is added. > > I think you are mistaken there: if we add the page fault fixup to make sure we > don't crash if a read-only variable is accessed, then we'll have most of the > benefits of read-only mappings and no fragility - without having to wait for > tooling. I guess the point PaX Team (and me earlier in this thread) wanted to make is that having misuse detection *only* at run-time will make those kind of bugs visible too late -- as late as on the wrong write attempt actually happening. It would be much better to have the compiler complain about invalid write statements already during compilation, much like it does when one wants to assign some value to a const object. Having the page fault handler being able to recover from __ro_after_init faults is a nice feature to support users, actually being able to report bugs. But it shouldn't be the only way to detect those kinds of bugs. In fact, we've tools in our toolchain that try to detect and flag wrong usage of __init / __exit, so why not cover __ro_after_init as well? Admitted, that won't be possible with modpost in its current state, but would require a compiler extension instead. Its current non-existence shouldn't be a show-stopper for __ro_after_init but the very next step to take care of before extending the usage of that annotation. Just my 2ct, Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Date | 2015-11-30 09:10 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qArH4-10J-11@gated-at.bofh.it> |
| In reply to | #1279385 |
* Mathias Krause <minipli@googlemail.com> wrote: > On 29 November 2015 at 16:39, Ingo Molnar <mingo@kernel.org> wrote: > > > > * PaX Team <pageexec@freemail.hu> wrote: > > > >> On 29 Nov 2015 at 9:08, Ingo Molnar wrote: > >> > >> > > >> > * PaX Team <pageexec@freemail.hu> 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. > >> > >> actually, i already voiced my opinion elsewhere in the constify thread on the > >> kernel hardening list that adding/using __read_only is somewhat premature > >> without also adding the compile time verification part (as part of the constify > >> plugin for example). right now its use on the embedded vdso image is simple and > >> easy to verify but once people begin to add it to variables that the compiler > >> knows and cares about (say, the ops structures) then things can become fragile > >> without compile checking. so yes, i'd also advise to get such tooling in > >> *before* more __read_only usage is added. > > > > I think you are mistaken there: if we add the page fault fixup to make sure we > > don't crash if a read-only variable is accessed, then we'll have most of the > > benefits of read-only mappings and no fragility - without having to wait for > > tooling. > > I guess the point PaX Team (and me earlier in this thread) wanted to > make is that having misuse detection *only* at run-time will make > those kind of bugs visible too late -- as late as on the wrong write > attempt actually happening. It would be much better to have the > compiler complain about invalid write statements already during > compilation, much like it does when one wants to assign some value to > a const object. Well, the runtime warning comes "later", that does not automatically transform into "too late". These things are relatively rare. Whether the warning is in tooling or runtime (or both) is relatively immaterial in that regard: having it in tooling would be nice, but it's not fool-proof either: say if tooling leaves an easy backdoor like allowing a type cast to supress warnings then it turns into a hard to debug problem again. So I think we need both, starting with the runtime warning which is easy to implement and can be merged right away. But reality is that upstream tooling changes, especially ones involving compiler changes move at a glacier's pace in comparison. Based on past experience I am also pretty pessimistic: I'm 90% certain that this 'tooling feature' won't be implemented in the next 10 years, so I'd like to concentrate on what we can do here and now: the runtime warning and recovery without crashing. If anyone sends patches for that I'll apply them. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-11-26 17:20 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qz7r3-7xJ-1@gated-at.bofh.it> |
| In reply to | #1278090 |
On Thu, Nov 26, 2015 at 12:54 AM, Ingo Molnar <mingo@kernel.org> wrote: > > * PaX Team <pageexec@freemail.hu> 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 >> > bring-up phase. Debugging that kind of problems is sort of a PITA, you >> > could imagine. > > ( Sidenote: I don't think a ro-faults typically result in triple faults, but yeah, > even having a regular oops (followed by a hang or reboot) during such an > undebuggable state of the system is a major PITA. ) > >> 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 property, log the >> event to dmesg and retry the faulting access. > > So a safer method would be to decode the faulting instruction, to skip it by > fixing up the return RIP and to log the event. It would be mostly equivalent to > trying to write to ROM (which get ignored as well), so it's a recoverable (and > debuggable) event. > > We have all the necessary code in place in the kprobes code, see > arch/x86/lib/insn.c, it's a simplified x86 decoder that knows about instruction > length (but not about semantics). > > Simple skipping plus setting arithmetic flags to init value should be enough I > think: I don't think we use fancy instructions to write to ro variables, such as > PUSH/POP with other side effects. If such instructions exist we could minimally > extend the decoder to do those fixups as well - in addition to double checking > that we skip simple instructions only with no side effects. > > Can you see any fragility in such a technique? > After Linus shot down my rdmsr/rwmsr decoding patch, good luck... More seriously, though, I think this is mostly just like any other in-kernel fault. We failed, me might be under attack, let's oops. In the particular case of suspend/resume, we could consider a debug flag to allow writes to these variables during suspend/resume. In fact, that might even be a reasonable default. We might want to allow writes during module unload as well. For everything else, we should probably focus more on getting OOPSes to display reliably, which is supposed to work but, on my shiny new i915-based laptop, is clearly not ready yet (I oopsed it yesterday due to my own bug and all I had to show for it was a blinking capslock key, and yes, modesetting works). --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Date | 2015-11-27 09:10 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qzmgq-eI-5@gated-at.bofh.it> |
| In reply to | #1278317 |
* Andy Lutomirski <luto@amacapital.net> 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 mostly just like any other in-kernel > fault. We failed, me might be under attack, let's oops. In the particular case > of suspend/resume, we could consider a debug flag to allow writes to these > variables during suspend/resume. In fact, that might even be a reasonable > default. We might want to allow writes during module unload as well. We are getting the _same_ information: we generate a reliable stack trace right there. We don't ignore anything. What my suggestion would do is to turn a 'sure system crasher' into a 'informational debug message'. On today's typical desktop systems I can tell you with 110% confidence that the vast majority of 'system crasher' oopses never reaches a kernel developer's attention, because the oops message is not propagated to the user, while the 'dump stack trace and try to continue' approach will result in proper bugzillas. And that's really an important distinction IMHO. Getting debug info out of the system is very important - and those who are paranoid can set a Kconfig value to crash their systems on any hint of a problem. > For everything else, we should probably focus more on getting OOPSes to display > reliably, which is supposed to work but, on my shiny new i915-based laptop, is > clearly not ready yet (I oopsed it yesterday due to my own bug and all I had to > show for it was a blinking capslock key, and yes, modesetting works). That's absolutely true as well but an independent issue: it does not invalidate my argument that is based on the status quo, which is that the vast majority panics/oopses, _especially_ during suspend/resume that was mentioned in this case, does not reach any kernel developer. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-11-27 19:10 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qzvD4-6jW-27@gated-at.bofh.it> |
| In reply to | #1278601 |
On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds
<torvalds@linux-foundation.org> 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 oops policy is, with the default
obviously being the normal "kill that particular thread" if at all
possible.
Machine-killing is appropriate in some secure situations, but most of
the time it just makes it too damn hard to debug since the error often
doesn't get logged. In some situations we obviously can't avoid it,
but..
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-11-27 19:10 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qzvD4-6jW-29@gated-at.bofh.it> |
| In reply to | #1278601 |
On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Andy Lutomirski <luto@amacapital.net> 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.
Yeah, no, I hate it. I'm with the PaX team on this one - I think there
are three valid responses, and I think we might want to have a dynamic
config option (kernel command line or proc or whatever) to pick
between the two:
- just oops and kill the machine, like for any other unhandled kernel
page fault. This is probably what you should have on a server
- 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
- have an option to disable the RO data logic.
I think that second option is good for debugging. In some places,
oopses that kill things are just too hard to debug (ie it might be the
modesetting or early boot or whatever).
In fact, I think we should _start_ with the second option - perhaps
just during the rc's - and then when we're pretty sure all the silly
bugs it finds (maybe none, who knows) are handled, we should go to the
first one.
The third option would be purely for "user that cannot fix things
directly and has reported the problem can now turn off the distracting
warning". We should never default to it.
Trying to actually *recover* any other way thanm by turning the area
read-write is just too damn fragile. You can't just skip over the
instruction that does the write - there are flags values etc that get
updated by read-modify-write instructions, but as PaX says, there nmay
also be subsequent logic that gets confused and actually introduces
even *more* problems downstream if the write is just discarded.
So maybe we could have some kind of "mark it read-only again later"
thing that tries to make sure it doesn't stay writable for a long
time, but quite frankly, I don't think it's worth it. Once the write
has been done, and the warning has been emitted, there's likely very
little upside to then trying to close the barn doors after that horse
has bolted.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2015-11-27 21:10 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qzxvb-7sb-1@gated-at.bofh.it> |
| In reply to | #1278916 |
On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar <mingo@kernel.org> wrote: >> >> * Andy Lutomirski <luto@amacapital.net> 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. > > Yeah, no, I hate it. I'm with the PaX team on this one - I think there > are three valid responses, and I think we might want to have a dynamic > config option (kernel command line or proc or whatever) to pick > between the two: > > - just oops and kill the machine, like for any other unhandled kernel > page fault. This is probably what you should have on a server This is how the v2 series works now. > - 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(), or should I only make the new ro-after-init section as RW? (I think the former would be easier.) > - have an option to disable the RO data logic. I added this as "rodata=off" in the v2 series. > I think that second option is good for debugging. In some places, > oopses that kill things are just too hard to debug (ie it might be the > modesetting or early boot or whatever). > > In fact, I think we should _start_ with the second option - perhaps > just during the rc's - and then when we're pretty sure all the silly > bugs it finds (maybe none, who knows) are handled, we should go to the > first one. > > The third option would be purely for "user that cannot fix things > directly and has reported the problem can now turn off the distracting > warning". We should never default to it. > > Trying to actually *recover* any other way thanm by turning the area > read-write is just too damn fragile. You can't just skip over the > instruction that does the write - there are flags values etc that get > updated by read-modify-write instructions, but as PaX says, there nmay > also be subsequent logic that gets confused and actually introduces > even *more* problems downstream if the write is just discarded. > > So maybe we could have some kind of "mark it read-only again later" > thing that tries to make sure it doesn't stay writable for a long > time, but quite frankly, I don't think it's worth it. Once the write > has been done, and the warning has been emitted, there's likely very > little upside to then trying to close the barn doors after that horse > has bolted. > > Linus -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-11-27 21:10 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qzxvc-7sb-3@gated-at.bofh.it> |
| In reply to | #1278940 |
On Fri, Nov 27, 2015 at 12:03 PM, Kees Cook <keescook@chromium.org> wrote: > On Fri, Nov 27, 2015 at 10:00 AM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> On Thu, Nov 26, 2015 at 11:59 PM, Ingo Molnar <mingo@kernel.org> wrote: >>> >>> * Andy Lutomirski <luto@amacapital.net> 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. >> >> Yeah, no, I hate it. I'm with the PaX team on this one - I think there >> are three valid responses, and I think we might want to have a dynamic >> config option (kernel command line or proc or whatever) to pick >> between the two: >> >> - just oops and kill the machine, like for any other unhandled kernel >> page fault. This is probably what you should have on a server > > This is how the v2 series works now. > >> - 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(), or should I only make the new ro-after-init section > as RW? (I think the former would be easier.) I'd suggest verifying that the page in question is .data..ro_after_init and, if so, marking that one page RW. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Date | 2015-11-29 09:10 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qA5dv-3H7-3@gated-at.bofh.it> |
| In reply to | #1278941 |
* Andy Lutomirski <luto@amacapital.net> 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(), or should I only make the new ro-after-init section as RW? > > (I think the former would be easier.) > > I'd suggest verifying that the page in question is .data..ro_after_init and, if > so, marking that one page RW. Yes, this was PaX's suggestion as well, and I agree: doing that turns a quite possibly unrecoverable boot/shutdown time or suspend/resume time (suspend is really a special category of 'bootup') crasher oops into a more informative stack dump. These ro related faults tend to trigger when init/deinit is running, and oopsing in those sequences is typically a lot less survivable than say oopsing in a high level system call while not holding locks. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2015-11-25 18:30 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qyM3h-RQ-9@gated-at.bofh.it> |
| In reply to | #1277122 |
On Wed, Nov 25, 2015 at 1:13 AM, Mathias Krause <minipli@googlemail.com> wrote: > On 24 November 2015 at 22:38, Kees Cook <keescook@chromium.org> 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 made read-only during mark_rodata_ro() >> which happens after all kernel __init code has finished. >> >> This introduces __read_only as a way to mark such memory, and uses it on >> the x86 vDSO to kill an extant kernel exploitation method. > > ...just some random notes on the experience with kernels implementing > such a feature for quite a lot of locations, not just the vDSO. > > 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" rule by writing to such > annotated variables from non-init code goes unnoticed as far as it > concerns the toolchain. Neither the compiler nor the linker will flag > that incorrect use. It'll just trap at runtime and that's bad. Well, or, it's good: that's the point of it. Either from the perspective of robustness or from that of security. > 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 kind of problems is sort of a PITA, you > could imagine. As PaX Team mentions, it should be easy to catch these traps and report them. That could certainly be a nice addition. > 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. The > initify and checker plugins from the PaX patch might be worth to look > at for that purpose, as they're doing similar things already. Adding > such a check to sparse might be worth it, too. > A modpost check probably won't work as it's unable to tell if it's a > legitimate access (r/o) or a violation (/w access). So the gcc plugin > is the way to go, IMHO. There are many more pieces to add to the annotation use, but I don't want to risk getting us into a Catch-22. Emese's work on the plugin side will see this usage and utility grow, and I think getting these basic building blocks in place is the right place to start. -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2015-11-25 18:40 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qyMcX-Vq-33@gated-at.bofh.it> |
| In reply to | #1277122 |
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" rule by writing to such > annotated variables from non-init code goes unnoticed as far as it > concerns the toolchain. Neither the compiler nor the linker will flag > that incorrect use. It'll just trap at runtime and that's bad. > > 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 kind of problems is sort of a PITA, you > could imagine. > > 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. The > initify and checker plugins from the PaX patch might be worth to look > at for that purpose, as they're doing similar things already. Adding > such a check to sparse might be worth it, too. > A modpost check probably won't work as it's unable to tell if it's a > legitimate access (r/o) or a violation (/w access). So the gcc plugin > is the way to go, IMHO. > 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 diagnosis. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2015-11-25 20:00 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qyNsm-1CU-17@gated-at.bofh.it> |
| In reply to | #1277647 |
On Wed, Nov 25, 2015 at 9:31 AM, H. Peter Anvin <hpa@zytor.com> 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 annotation), it has its >> drawbacks. Violating the "r/o after init" rule by writing to such >> annotated variables from non-init code goes unnoticed as far as it >> concerns the toolchain. Neither the compiler nor the linker will flag >> that incorrect use. It'll just trap at runtime and that's bad. >> >> 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 kind of problems is sort of a PITA, you >> could imagine. >> >> 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. The >> initify and checker plugins from the PaX patch might be worth to look >> at for that purpose, as they're doing similar things already. Adding >> such a check to sparse might be worth it, too. >> A modpost check probably won't work as it's unable to tell if it's a >> legitimate access (r/o) or a violation (/w access). So the gcc plugin >> is the way to go, IMHO. >> > > 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 diagnosis. Seems easiest to have an arg just skip calling mark_rodata_ro(). I can add that. -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2015-11-25 20:10 +0100 |
| Subject | Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory |
| Message-ID | <qyNC2-1Wc-23@gated-at.bofh.it> |
| In reply to | #1277697 |
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 diagnosis. > > Seems easiest to have an arg just skip calling mark_rodata_ro(). I can add that. > Exactly. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web