linux-kernel - Re: [GIT PULL] tomoyo update for v6.12

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7dce903c-2f76-43b2-bb6f-808cb50d0696@I-love.SAKURA.ne.jp>
Date: Sun, 29 Sep 2024 00:32:18 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Jonathan Corbet <corbet@....net>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Paul Moore <paul@...l-moore.com>
Subject: Re: [GIT PULL] tomoyo update for v6.12

On 2024/09/28 22:54, Jonathan Corbet wrote:
>> I was delivering pure LKM version of TOMOYO (named AKARI) to users who
>> cannot afford rebuilding their distro kernels with TOMOYO enabled. But
>> since the LSM framework was converted to static calls, it became more
>> difficult to deliver AKARI to such users. Therefore, I decided to update
>> TOMOYO so that people can use mostly LKM version of TOMOYO with minimal
>> burden for both distributors and users.
> 
> I must confess that this change confuses me a bit.  Loadable LSM modules
> have been out of the picture for a long time, has that changed now?

No, the loadable LSM modules had been in the picture since 2010. There had been
many on-list and off-list discussions for how to support loadable LSM modules.

Since Casey Schaufler had been working on multiple concurrent LSM modules,
with a promise that we won't make changes that make loadable LSMs impossible
( https://lkml.kernel.org/r/ed785c86-a1d8-caff-c629-f8a50549e05b@I-love.SAKURA.ne.jp ),
I was waiting for Casey's work to complete. Meanwhile, I was using loadable
LSMs as out-of-tree code.

> Even stranger, to me at least, is the backdoor symbol-export mechanism.
> That seems like ... not the way we do things.  Was the need for this so
> urgent that you couldn't try to get those symbols exported properly?

Yes. This is a chicken-and-egg problem. Symbols not used by in-tree kernel
code cannot be justified for export, but I can't prove that loadable LSM
can work unless I export symbols. This became an urgent chicken-and-egg
problem due to "static calls" changes which went to this merge window
( https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp ).

KP Singh has suggested an approach
( https://lkml.kernel.org/r/CACYkzJ7_42dhynhmuCBF6z0hyMkYL_FxLR9rM1beCwJVkEv9gQ@mail.gmail.com )
and I posted what KP Singh has suggested
( https://lkml.kernel.org/r/d1e5b74a-5161-4906-96eb-4987ff440d19@I-love.SAKURA.ne.jp )
but Paul Moore refused what KP Singh has suggested
( https://lkml.kernel.org/r/CAHC9VhT_eBGJq5viU8R_HVWT=BTcxesWAi3nLcMgG8NfswKesA@mail.gmail.com ).

Since Paul Moore continues ignoring my concerns, waiting for support of loadable
LSMs at LSM framework layer won't help. I had to express my concerns and
demonstrate/prove that loadable LSM can work immediately. I know that people shall
forget my concerns if I didn't take action right now.

This backdoor symbol-export mechanism is a transitional hack needed for
demonstrating that loadable LSM can work. This hack will be replaced with
proper symbol-export via appropriate trees after this merge window closes.