[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: exec-shield (maybe ITP kernel-patch-exec-shield)

On Fri, 28 Nov 2003 11:43, Zenaan Harkness <zen@iptaustralia.net> wrote:
> As I understand it, having a separate patch package is simply a
> procedural issue within Debian - unless you can convince the current
> kernel packager to include your desired (or our desired, when
> debian-enterprise decides PAX is a required goal) patch into the kernel
> immediately. The point is, when a patch (Debian packaged) is firstly
> made available, a bunch of people can go test it, report bugs if there
> are any, submit patches (eg. for other packages that might need changes
> to work with it), and if it is eventually "popular enough", it might
> even get into the kernel proper.

For an "Enterprise" distribution of Linux the first priority will be 
delivering reliable operation and decent performance under heavy load.  The 
Red Hat kernels are good for this, they have many features such as Ext3 
directory hashing back-ported from 2.6 to 2.4 kernels.  They also have some 
bug fixes for serious performance bugs (such as IO performance sucking under 
heavy load on 2.4.x kernels with >=4G of RAM).

Exec-shield is also going into the Red Hat kernels.  So if Debian adopts a Red 
Hat kernel for it's enterprise release then exec-shield will come as part of 

Producing a kernel source tree based on the Red Hat kernel tree but with PaX 
instead of exec-shield may take some work, and this may take more time and 
skill than is available.

We can expect that taking the Red Hat kernel source is an option for on-going 
support of an enterprise kernel.  Is someone prepared to commit to on-going 
work in producing Red Hat kernel source trees with PaX?

> Some of our users (eg. one of my boxes - the one dedicated to my band)
> have real-time scheduling and latency as highest priority. It is not
> even connected to the net, and thus security is a non-issue. And it
> would require more effort *for me and the band as Debian-multimedia
> users* to have to back out security patches that lowered our real-time
> audio performance. Of course, now that the debian-multimedie sub project

I am not aware of any security patches hurting that performance.  Security 
patches will slightly decrease performance, but you are generally looking at 
less than 5% for most operations and less than 10% for the worse cases (such 
as Gig-E networking).  If such a small performance difference will break your 
system then you probably have problems already.

Also I am not aware of any security patches giving worse real-time 
performance.  They just increase the time taken to complete operations.

http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Reply to: