Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1278601

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

From Ingo Molnar <mingo@kernel.org>
Newsgroups linux.kernel
Subject Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory
Date 2015-11-27 09:10 +0100
Message-ID <qzmgq-eI-5@gated-at.bofh.it> (permalink)
References <qyttF-59Z-27@gated-at.bofh.it> <qyEp4-4c9-15@gated-at.bofh.it> <qyG7w-5tK-23@gated-at.bofh.it> <qz0zf-2JX-7@gated-at.bofh.it> <qz7r3-7xJ-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


* 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/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[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

csiph-web