On 12/16/19 6:46 PM, Paul Moore wrote:
On Mon, Dec 16, 2019 at 9:21 AM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
On 12/14/19 1:50 PM, Dan Aloni wrote:
On Fri, Dec 13, 2019 at 03:28:38PM -0500, Stephen Smalley wrote:
I would have expected that two kernels built with the same config
with this enabled would have yielded different struct layouts in
pahole vmlinux output, but that doesn't appear to be the case. They
do have different seeds. Am I doing something wrong?
Also, does DEBUG_INFO_BTF effectively undermine/negate the benefits of this
change if enabled?
There's currently a long-standing bug with the GCC plugin where the
generated debug info is in declaration order, not build order (see:
[1]). So, to verify it, try looking at the generated machine code.
Thanks for that clarification; I can see in the code that the struct
layout has changed between the two kernel builds.
This likely falls under the category of stupid questions, but I'm
assuming it passed the test suite w/o problems and the system
generally ran as expected?
Yes, it tested fine for me. It did require a full rebuild to ensure that
the randomized struct layouts were being used consistently throughout,
and requires a make mrproper or distclean to remove the random seed
before rebuilding if you want to generate a new random seed.
I've also heard some comments about performance concerns, have you
done any testing? I'm guessing that isn't a major concern here
because I don't recall any of the structs marked in this patch going
through any optimizations, but I could be forgetting something (or
missing a performance concern with RANDSTRUCT).
I haven't done any specific performance testing, but it will only impact
users who enable RANDSTRUCT, so it is entirely opt-in, and as you say,
these structs have not been especially optimized in the first place.
I think these same structures (or at least significant subsets thereof)
are good candidates for write-rare protections if those ever reach
mainline. Haven't seen any progress there in a while.
