| |||||||||||||
Kernel security, year to dateKernel security, year to datePosted 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 (subscriber, #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
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
my experience says otherwise:
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 (subscriber, #15203) [Link]
> why does something have to be in mainline to benefit everyone?
It doesn't have to be in mainline to benefit everyone.
> > Expecting kernel developers to go to the PaX team
> any source for this (rather silly, i might add)
I think you're missing the point he was making.
If you want patches to go into mainline (and we just saw
Possibly developing and testing their own code and
|
|||||||||||||