[GIT PULL] tomoyo update for v6.12

[Tetsuo Handa]

On 2024/10/03 15:16, Tetsuo Handa wrote:
>>> TOMOYO is one of in-tree modules that can be signed together when building
>>> distribution kernels. Fedora can provide tomoyo.ko as a signed-but-unsupported
>>> module (i.e. excluded from main kernel package that is supported by
>>> distributors but provided as a separate package that is not supported by
>>> distributors).
>>>
>> yes it can, it has chosen not to. As I have said before that is
>> a choice/political reason, not technical. I wish I had a solution to this
>> problem for you but I don't.
> 
> What does "it" referring to? Fedora has chosen not to build TOMOYO into Fedora's
> vmlinux. But I haven't heard from Fedora that Fedora won't ship tomoyo.ko as a
> separate package.

Currently, a Linux distributor is an entity that provides kernel program and
userspace program. But as the kernel code signing getting more important,
the role of a Linux distributor regarding the kernel program might change as
below?

Currently, people expect that "distributor takes care of handling all bugs
that happens with kernel code built by that distributor". Due to bandwidth
problem, distributor needs to disable kernel code which that distributor cannot
take care of bugs. My understanding is that some distributors started providing
separated kernel packages; the kernel package which that distributor can take
care of bugs and the kernel package which that distributor cannot take care of
bugs. The tomoyo.ko change is intended for being included in the latter package
if that distributor cannot include in the former package.

Since distributor needs to sign kernel code, I think this separation is becoming
more inevitable. That is, people might need to change their expectation to that
"distributor takes care of handling bugs that happens with kernel code in the
former package, and somebody takes care of handling bugs that happens with kernel
code in the latter package", and distributor's role is to compile as many kernel
code as possible and sign all compiled kernel code so that the kernel code is
compiled and shipped (and not tampered) by known entities; something like SSL
certificates providers.