From: Guenter Roeck <linux@roeck-us.net>
To: KP Singh <kpsingh@kernel.org>, Paul Moore <paul@paul-moore.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, bp@alien8.de,
sfr@canb.auug.org.au, peterz@infradead.org,
ink@jurassic.park.msu.ru, richard.henderson@linaro.org
Subject: Re: [PATCH] init/main.c: Initialize early LSMs after arch code
Date: Mon, 12 Aug 2024 21:07:56 -0700 [thread overview]
Message-ID: <b3c04f8a-b7e9-4dc7-849e-aeaed508b8cf@roeck-us.net> (raw)
In-Reply-To: <CACYkzJ5J8K2D8xqT+CCrbvp57P=GbCB+XYXkAaKXojsFhuaWEw@mail.gmail.com>
On 8/12/24 15:02, KP Singh wrote:
> On Mon, Aug 12, 2024 at 11:33 PM Paul Moore <paul@paul-moore.com> wrote:
>>
>> On Mon, Aug 12, 2024 at 5:14 PM KP Singh <kpsingh@kernel.org> wrote:
>>> On Mon, Aug 12, 2024 at 9:33 PM Paul Moore <paul@paul-moore.com> wrote:
>>>> On Mon, Aug 12, 2024 at 1:12 PM KP Singh <kpsingh@kernel.org> wrote:
>>>>>
>>>>> JFYI, I synced with Guenter and all arch seem to pass and alpha does
>>>>> not work due to a reason that I am unable to debug. I will try doing
>>>>> more debugging but I will need more alpha help here (Added the
>>>>> maintainers to this thread).
>>>>
>>>> Thanks for the update; I was hoping that we might have a resolution
>>>> for the Alpha failure by now but it doesn't look like we're that
>>>> lucky. Hopefully the Alpha devs will be able to help resolve this
>>>> without too much trouble.
>>>>
>>>> Unfortunately, this does mean that I'm going to drop the static call
>>>> patches from the lsm/dev branch so that we can continue merging other
>>>> things. Of course this doesn't mean the static call patches can't
>>>> come back in later during this dev cycle once everything is solved if
>>>> there is still time, and worst case there is always the next dev
>>>> cycle.
>>>>
>>>
>>> Do we really want to drop them for alpha? I would rather disable
>>> CONFIG_SECURITY for alpha and if people really care for alpha we can
>>> enable it. Alpha folks, what do you think?
>>
>> Seriously? I realize Alpha is an older, lesser used arch, but it is
>> still a supported arch and we are not going to cause a regression for
>> the sake of a new feature. As I mentioned earlier, once the problem
>> is resolved we can bring the patchset back into lsm/dev; if it gets
>> resolved soon enough we can even do it during this dev cycle.
>>
>
> Okay, more data for the alpha folks, when I moved trap_init() before
> early_security_init() everything seemed to work, I think we might need
> to call trap_init() from setup_arch and this would fix the issue. As
> to why? I don't know :)
>
> Would alpha folks be okay with this patch:
>
> kpsingh@kpsingh:~/projects/linux$ git diff
> diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c
> index bebdffafaee8..53909c1be4cf 100644
> --- a/arch/alpha/kernel/setup.c
> +++ b/arch/alpha/kernel/setup.c
> @@ -657,6 +657,7 @@ setup_arch(char **cmdline_p)
> setup_smp();
> #endif
> paging_init();
> + trap_init();
> }
>
>
> and provide me some reason as to why this works, it would be great for
> a patch description
>
Your code triggers a trap (do_entUna, unaligned access) which isn't handled unless
trap_init() has been called before.
Reason is that static_calls_table is not 8-byte aligned, causing the unaligned
access in:
static void __init lsm_static_call_init(struct security_hook_list *hl)
{
struct lsm_static_call *scall = hl->scalls;
int i;
for (i = 0; i < MAX_LSM_COUNT; i++) {
/* Update the first static call that is not used yet */
if (!scall->hl) { <-- here
__static_call_update(scall->key, scall->trampoline,
hl->hook.lsm_func_addr);
scall->hl = hl;
static_branch_enable(scall->active);
return;
}
scall++;
}
panic("%s - Ran out of static slots.\n", __func__);
}
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) \
(struct lsm_static_call) { \
.key = &STATIC_CALL_KEY(LSM_STATIC_CALL(NAME, NUM)), \
Guenter
next prev parent reply other threads:[~2024-08-13 4:07 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 17:17 [PATCH] init/main.c: Initialize early LSMs after arch code KP Singh
2024-08-05 19:57 ` Paul Moore
2024-08-05 23:29 ` KP Singh
2024-08-06 2:20 ` Nathan Chancellor
2024-08-06 21:41 ` Paul Moore
2024-08-07 20:44 ` Paul Moore
2024-08-07 22:45 ` KP Singh
2024-08-07 22:50 ` KP Singh
2024-08-07 23:43 ` Paul Moore
2024-08-08 0:30 ` KP Singh
2024-08-08 0:34 ` Guenter Roeck
2024-08-08 0:40 ` KP Singh
2024-08-08 1:20 ` Guenter Roeck
2024-08-08 1:18 ` Paul Moore
2024-08-08 1:40 ` Guenter Roeck
2024-08-08 2:13 ` Guenter Roeck
2024-08-08 4:07 ` Guenter Roeck
2024-08-08 9:57 ` KP Singh
2024-08-08 15:20 ` Guenter Roeck
2024-08-08 16:43 ` Guenter Roeck
2024-08-08 17:32 ` Paul Moore
2024-08-08 18:00 ` Guenter Roeck
2024-08-08 20:49 ` Paul Moore
2024-08-12 17:12 ` KP Singh
2024-08-12 19:33 ` Paul Moore
2024-08-12 21:14 ` KP Singh
2024-08-12 21:32 ` Paul Moore
2024-08-12 22:02 ` KP Singh
2024-08-13 4:07 ` Guenter Roeck [this message]
2024-08-13 15:56 ` KP Singh
2024-08-13 16:26 ` Guenter Roeck
2024-08-13 18:21 ` Paul Moore
2024-08-08 17:19 ` Paul Moore
2025-03-11 13:37 ` joeyli
2025-03-11 15:14 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b3c04f8a-b7e9-4dc7-849e-aeaed508b8cf@roeck-us.net \
--to=linux@roeck-us.net \
--cc=bp@alien8.de \
--cc=ink@jurassic.park.msu.ru \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=paul@paul-moore.com \
--cc=peterz@infradead.org \
--cc=richard.henderson@linaro.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox