Re: thoughts on kernel security issues

[Christoph Hellwig]

On Thu, Jan 20, 2005 at 01:16:33PM -0500, John Richard Moser wrote:
> Granted, you're somewhat more diverse than I pointed out; but I don't
> keep up on what you're doing.  The point was more that you're not a
> major security figure and/or haven't donated your life to security and
> forsaken all lovers before it like Joshua Brindle or Brad Spengler or
> whoever the anonymous guy who developes PaX is.  I guess less focus on
> the developer and more focus on the development.

But Ingo is someone who

 - is a known allround kernel hacker
 - has a trackrecord of getting things done that actually get used
 - lowlevel CPU knowledge
 - is able to comunicate with other developers very well
 - is able to make good tradeoffs
 - has taste

most of that can't be said for your personal heroes

> *shrug*  The kernel's basic initialization code is in assembly.  On 40
> different platforms.  That's pretty complex in terms of kernel code,
> which is 99.998% C.

No, the kernel initialization is not complex at all.  complexity != code size

> Which brings us to a point on (1) and (2).  You and others continue to
> pretend that SEGMEXEC is the only NX emulation in PaX.  I should remind
> you (again) that PAGEEXEC uses the same method that Exec Shield uses
> since I believe kernel 2.6.6.  In the cases where this method fails, it
> falls back to kernel-assisted MMU walking, which can produce potentially
> high overhead.

You stated that a few time.  Now let's welcome you to reality:

 - Linus doesn't want to make the tradeoffs for segment based NX-bit
   emulation in mainline at all
 - Ingo and his collegues at Red Hat want to have it, but they don't
   want to break application nor introduce the addition complexity
   of the PaX code.

Is is that hard to understand?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/