lkml.org 
[lkml]   [2015]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

    * PaX Team <pageexec@freemail.hu> wrote:

    > On 26 Nov 2015 at 11:42, Ingo Molnar wrote:
    >
    > > * PaX Team <pageexec@freemail.hu> 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/dropping such writes could cause all kinds of logic bugs (if not
    > > > worse).
    > >
    > > Well, the typical case is that it's a logic bug to _do_ the write: the structure
    > > was marked readonly for a reason but some init code re-runs during suspend or so.
    >
    > that's actually not the typical case in my experience, but rather these two:
    >
    > 1. initial mistake: someone didn't actually check whether the given object can
    > be __read_only
    >
    > 2. code evolution: an object that was once written by __init code only (and
    > thus proactively subjected to __read_only) gets modified by non-init code
    > due to later changes
    >
    > what you described above is a third case where there's a latent bug to begin
    > (unintended write) with that __read_only merely exposes but doesn't create
    > itself, unlike the two cases above (intended writes getting caught by wrong use
    > of __read_only).

    You are right, I concede this part of the argument - what you describe is probably
    the most typical way to get ro-faults.

    I do maintain the (sub-)argument that oopsing or relying on tooling help years
    down the line is vastly inferior to fixing up the problem and generating a
    one-time stack dump so that kernel developers have a chance to fix the bug. The
    sooner we detect and dump such information the more likely it is that such bugs
    don't get into end user kernel versions.

    > my proposal would produce the exact same reports, the difference is in letting
    > the write attempt succeed vs. skipping it. this latter step is what is wrong
    > since it introduces at least a logic bug the same way the constprop optimization
    > created a logic bug.

    Yes, you are right and I agree.

    Does anyone want to submit such a patch for upstream? Looks like a good change.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2015-11-27 09:21    [W:3.200 / U:0.736 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site