Re: thoughts on kernel security issues

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Christoph Hellwig wrote:
> 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
> 

That's all good, but I notice being exceedingly competant in the needs
of a proper secured environment is lacking in your list.  Is he
exceedingly knowledgible about security?  Who is he working with who
will fill in his gaps in understanding if not?

The PaX developer may not be well known, or have anything in the kernel,
but I've talked to the guy.  He has CPU manuals for practically
everything, and *gasp* he READS them!  He maintains PaX himself, and it
works well on my AMD64; he has the manual, but not the CPU.

The trade-off of SEGMEXEC is 50% of VM space and 0.7% CPU.  The
trade-off of PAGEEXEC (on x86; a real NX bit is used on other CPUs) is
identical to Exec Shield's until that method fails, then it falls back
to a potentially very painful CPU trade-off that's necessary to continue
to offer a supported NX bit.

Explain "Taste."

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

I was more pointing out that it was assembler code.  Clean and simple as
it may be, you come back in 10 years and try to maintain it.

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

It's an option, set in menuconfig.  It's not a forced trade-off, so
integrating it (btw I wasn't and am not currently arguing to get PaX
integrated) wouldn't really force a trade-off on the user.

Back to the above, this argument doesn't cover page-based NX-bit emulation.

>  - 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.
> 

Nor guarantee that the NX emulation is actually durable.

> Is is that hard to understand?
> 
> 

What's hard to understand is the constant banter about SEGMEXEC when
there's a second mode AND when it's completely optional.  Are you trying
to make it sound like you're pretending that PaX isn't innovative and
that the trade-offs are obscene and infeasible in an every-day
environment?  Why is PAGEEXEC ignored in every argument, and SEGMEXEC
focused on, when one or both can be disabled so that the VM split goes away?

Could it be that you can't argue against PAGEEXEC because it uses the
exact same method that Exec Shield uses, and falls back to a heavier one
when that fails; yet you argue that Exec Shield shouldn't fail except in
extremely rare cases, so you can't hold the possibly heavy-overhead case
in PAGEEXEC to question without invalidating your own arguments?

What's wrong with PAGEEXEC?  Why focus on SEGMEXEC?

The only thing I ever complain about concerning Exec Shield's principle
implementation is that it can fail in certain conditions.  the
deployment side (PT_GNU_STACK and automated marking) I don't even know
why I touched on; perhaps I should try to separate ES from RedHat's
overall smoke-and-mirrors approach to security, since ES at least
supplies a partially functional and reciprocating NX-ASLR proteciton.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB8CGphDd4aOud5P8RAlq/AJ40TYCxoUMi2PsWvZz/BqHsugEnuQCeL5iC
y2Ot5pTwi+1dbPKN+6WYU4k=
=Weu3
-----END PGP SIGNATURE-----
-
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/