Re: RFC: CCC Linux Kernel SIG

[Dan Middleton <dan.middleton@linux.intel.com>]

On 11/9/23 12:38 PM, James Bottomley wrote:
> On Tue, 2023-11-07 at 19:24 -0600, Dan Middleton wrote:
>> One of the technical limitations to the adoption rate for
>> Confidential Computing is the speed at which we as a community can
>> add features to the Linux kernel. Each vendor has similar needs of
>> the kernel but has historically presented significantly different
>> ABIs. To  contain complexity and manage maintainability, the Linux
>> kernel community tries to prevent proliferation of unnecessarily
>> vendor specific ABIs. Often the opportunity for commonality is
>> unclear until multiple vendors have proposed separate interfaces [0].
> The kernel community would see this as a feature not a bug.  It's very
> difficult to appreciate the technical ramifications until you see the
> actual code so even though it seems like more work in the beginning it
> produces better and faster outcomes in the end.
>
> To give the counter point to your example: each CC implementation had
> its own ioctl set.  The proposal unifies it through a configfs
> interface, but it's still not clear that the unification covers all the
> use cases.  This, though, can be worked through after the acceptance of
> the configfs pull request.  Adding ioctls is fairly simple, so there
> wasn't really much wasted work before agreement was reached on a
> preliminary design for configfs which can now be worked on by everyone.
>
> [...]

I agree we got there, but the path was quite long.
This might be the point where the second vendor ioctl was proposed which
would eventually give rise to the observation that a profusion of ioctl's
is bad:
https://lore.kernel.org/all/cover.1624719668.git.sathyanarayanan.kuppuswamy@linux.intel.com/

That was June 2021. It's now November 2023.

>> The Linux kernel community has not been a regular part of
>> discussions and the CCC has not been a regular participant on the
>> Linux Kernel Mail List (LKML)[1].
> Isn't this the current key problem with an obvious solution: the
> interested members of the CCC can simply join the lists.  You could
> make them do a formalised readout back to the CCC for people who don't
> want to be at the kernel list sharp end and establish an action plan
> from there if things are perceived to be going wrong.

I think that's a great suggestion.
That probably catches things already on the list.

What about getting in front of things before that stage?

>> The pipeline of activity is expected (but not required) to look like
>> this:
>> 1. Identify feature need on mailing list or informal forum.
>> 2. Exchange community proposals in the SIG.
>> 3. Achieve informal consensus in the SIG.
>>
>>       a. Author patches and take them to the appropriate community,
>> e.g., LKML.
> This really isn't the correct workflow for the Kernel.  The kernel
> likes to see sketches in code when arguing about ABI and design.
>
> The process really already works like your 1,2,3 with the exception
> that 1. begins on the kernel or KVM list.  Trying to achieve consensus
> in some other industrial forum and then present the patches to the list
> as the unified consensus hasn't really worked out well in the past
> (NVMe still has the scars to prove this).
>
> [...]
That's really interesting. I'd love any references about what didn't work
and what did work.

I think we could revise step 1 to read like.. learn about upcoming
features in the SIG and then recognize whether those will have kernel
impacts.

For example, it looks like most CPU vendors will be offering different
analogs of runtime measurement registers.

TEE-IO is coming down the pipe from CPU and device vendors.

There are software vendors working on novel use cases which might
imply different access patterns.

Would the CCC facilitating a mechanism to generate these cross-vendor
conversations be helpful?

What else would be helpful?

Thanks,
Dan Middleton