User: Password:
|
|
Subscribe / Log in / New account

Kernel security, year to date

Kernel security, year to date

Posted Sep 11, 2008 9:58 UTC (Thu) by intgr (subscriber, #39733)
In reply to: Kernel security, year to date by spender
Parent article: Kernel security, year to date

The rest of your post I can mostly agree with, but this statement of yours is completely backwards:

The PaX team recently has added a feature which prevents exploitation of refcount-based bugs (like the ptrace ones listed in the CVEs in this article). So there are always things that can be done with negligible impact, but don't hold your breath waiting for it to come from the kernel developers themselves.

If there are security enhancements that have (supposedly) negligible overhead, then why are not they being pushed towards the mainline where they can benefit everyone? Expecting kernel developers to go to the PaX team begging for their patch is not the way mainline development works. You go as far as to imply that the mainline kernel developers should duplicate this effort -- why?

Supposedly, getting patches into the kernel is easy with the current development model. Yes, they have different ideas about how security should be managed, but they are reasonable people. Why is the PaX team not interested in working with the mainline kernel?


(Log in to post comments)

Kernel security, year to date

Posted Sep 11, 2008 13:47 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> If there are security enhancements that have (supposedly) negligible
> overhead, then why are not they being pushed towards the mainline where
> they can benefit everyone?

why does something have to be in mainline to benefit everyone?

> Expecting kernel developers to go to the PaX team begging for their
> patch is not the way mainline development works.

any source for this (rather silly, i might add) allegiation? last time i checked, the PaX patches were out there freely available to everyone.

> Supposedly, getting patches into the kernel is easy with the current
> development model. Yes, they have different ideas about how security
> should be managed, but they are reasonable people.

my experience says otherwise:

http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-07/m...
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-07/m...
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-07/m...

(unfortunately vger's spam filter ate my mails, so you'll have to piece the story together from the quoted parts). the funny thing is that since last year, when CFS (by Ingo, no less) went into the kernel, it too became victim of the user_mode() mess in that now if you run an endless loop in v86 mode, its runtime will be accounted as system time, not user time. to quote Linus: 'Sad.'

> Why is the PaX team not interested in working with the mainline kernel?

it's the other way around: i've been told explicitly and got it even codified in DCO that anonymous submissions are not to be. i prefer my status over silly policies.

Kernel security, year to date

Posted Sep 11, 2008 16:02 UTC (Thu) by pdundas (guest, #15203) [Link]

> why does something have to be in mainline to benefit everyone?

It doesn't have to be in mainline to benefit everyone.
But putting fixes in mainline DOES benefit everyone.
Putting them anywhere else only benefits a subset of users.

> > Expecting kernel developers to go to the PaX team
> > begging for their patch is not the way mainline
> > development works.

> any source for this (rather silly, i might add)
> allegiation? last time i checked, the PaX patches
> were out there freely available to everyone.

I think you're missing the point he was making.

If you want patches to go into mainline (and we just saw
that is A Good Thing (TM)), then Someone (TM) has to
submit that patch.

Possibly developing and testing their own code and
reviewing submissions keeps mainline kernel devs
quite busy. They may not have all that much time for
scouring the net for potentially useful patches.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds