On 11/30/2023 1:34 PM, Roberto Sassu wrote: > On 11/30/2023 5:15 PM, Casey Schaufler wrote: >> On 11/30/2023 12:30 AM, Petr Tesarik wrote: >>> Hi all, >>> >>> On 11/30/2023 1:41 AM, Casey Schaufler wrote: >>>> ... >>>> It would be nice if the solution directly addresses the problem. >>>> EVM needs to be after the LSMs that use xattrs, not after all LSMs. >>>> I suggested LSM_ORDER_REALLY_LAST in part to identify the notion as >>>> unattractive. >>> Excuse me to chime in, but do we really need the ordering in code? >> >> tl;dr - Yes. >> >>> FWIW >>> the linker guarantees that objects appear in the order they are seen >>> during the link (unless --sort-section overrides that default, but this >>> option is not used in the kernel). Since *.a archive files are used in >>> kbuild, I have also verified that their use does not break the >>> assumption; they are always created from scratch. >>> >>> In short, to enforce an ordering, you can simply list the corresponding >>> object files in that order in the Makefile. Of course, add a big fat >>> warning comment, so people understand the order is not arbitrary. >> >> Not everyone builds custom kernels. > > Sorry, I didn't understand your comment. Most people run a disto supplied kernel. If the LSM ordering were determined only at compile time you could never run a kernel that omitted an LSM. > Everyone builds the kernel, also Linux distros. What Petr was > suggesting was that it does not matter how you build the kernel, the > linker will place the LSMs in the order they appear in the Makefile. > And for this particular case, we have: > > obj-$(CONFIG_IMA) += ima/ > obj-$(CONFIG_EVM) += evm/ > > In the past, I also verified that swapping these two resulted in the > swapped order of LSMs. Petr confirmed that it would always happen. LSM execution order is not based on compilation order. It is specified by CONFIG_LSM, and may be modified by the LSM_ORDER value. I don't understand why the linker is even being brought into the discussion. > > Thanks > > Roberto
