Re: [Xen-devel] [kernel-hardening] Re: x86: PIE support and option to extend KASLR randomization

[Pavel Machek <pavel@xxxxxx>]

Hi!

> > +         The kernel and modules will generate slightly more assembly (1 to 
> > 2%
> > +         increase on the .text sections). The vmlinux binary will be
> > +         significantly smaller due to less relocations.
> >
> > ... but describing a 1-2% kernel text size increase as "slightly more 
> > assembly"
> > shows a gratituous disregard to kernel code generation quality! In reality 
> > that's
> > a huge size increase that in most cases will almost directly transfer to a 
> > 1-2%
> > slowdown for kernel intense workloads.
> >
> > Where does that size increase come from, if PIE is capable of using relative
> > instructins well? Does it come from the loss of a generic register and the
> > resulting increase in register pressure, stack spills, etc.?
> >
> > So I'm still unhappy about this all, and about the attitude surrounding it.
> 
> Is the expectation then to have security functions also decrease size
> and operational latency? Seems a bit unrealistic if so.
> 1-2% performance hit on systems which have become at least several
> hundred % faster over recent years is not a significant performance
> regression compared to the baseline before.

We are probably willing to trade security for 2% performance impact...
if you can show that same security advantage can't be achieved without
the impact (and it is opt-in and documented and so on).

Kernel is not really a bottleneck for many people. For me, even CPUs
are not bottleneck, disk is.

But what is not okay is "hey, this is security, I can slow things
down. Merge it, because... security!".

Best regards,

                                                                        Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel