On Tue, Dec 17, 2019 at 8:43 AM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > 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. Okay, thanks. I think it's worth getting this now, even if there is some question about how widely they will be used. At least they will be there and we can use this as a starting point. Thanks for putting this patch together, but as a FYI, I did take the liberty to remove the double semi-colon during the merge ;) -- paul moore www.paul-moore.com
