Re: [PATCH] init/main.c: Initialize early LSMs after arch code

[Guenter Roeck <linux@roeck-us.net>]

On 8/13/24 08:56, KP Singh wrote:
> On Tue, Aug 13, 2024 at 6:08 AM Guenter Roeck <linux@roeck-us.net> wrote:
[ ... ]
>> A somewhat primitive alternate fix is:
>>
>> diff --git a/security/security.c b/security/security.c
>> index aa059d0cfc29..dea9736b2014 100644
>> --- a/security/security.c
>> +++ b/security/security.c
>> @@ -156,7 +156,7 @@ static __initdata struct lsm_info *exclusive;
>>     * and a trampoline (STATIC_CALL_TRAMP) which are used to call
>>     * __static_call_update when updating the static call.
>>     */
>> -struct lsm_static_calls_table static_calls_table __ro_after_init = {
>> +struct lsm_static_calls_table static_calls_table __ro_after_init __attribute__((aligned(8))) = {
>>    #define INIT_LSM_STATIC_CALL(NUM, NAME)                                        \
> 
> I think it's worth making it aligned at 8 byte, a much simpler fix
> than the arch change. Paul, I will rebase my series with these
> patches, better descriptions and post them later today.
> 

I think that would make sense, since it might well be that other architectures
have similar problems but it isn't seen because static_calls_table just happens
to be aligned properly there. Also, even if unaligned accesses that early were
supported, it is probably undesirable to have those in the running code if it
can be avoided due to the overhead involved.

With the above change:

Build results:
	total: 158 pass: 158 fail: 0
Qemu test results:
	total: 539 pass: 539 fail: 0
Unit test results:
	pass: 370886 fail: 3

There are a couple of caveats, unrelated to your patch series:
- I can not enable (and thus not test) security configurations
   on sh4 and sh4eb; doing so results in immediate qemu crashes.
- I can not enable / test security configurations on riscv32
   since it results in kernel images getting too large to fit
   into the available memory. I'll try to work around it,
   but for now I can only test with riscv64.

Guenter