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