On Tue, 28 Jun 2022 at 00:38, Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> wrote: > > On Mon, Jun 27, 2022 at 06:33:51PM +0200, Ard Biesheuvel wrote: > > > > > > > > > > > > Just as an idea, we can put info into UTS_VERSION which can be read from > > > > > > the built bzImage. We have info on SMP and preeption there already. > > > > > > > > > > > > > > > > Instead of hacking this into the binary, couldn't we define a protocol > > > > > that the kernel will call from the EFI stub (before EBS()) to identify > > > > > itself as an image that understands unaccepted memory, and knows how > > > > > to deal with it? > > > > > > > > > > That way, the firmware can accept all the memory on behalf of the OS > > > > > at ExitBootServices() time, unless the OS has indicated there is no > > > > > need to do so. > > > > > > > > I agree it would be better. But I think it would require change to EFI > > > > spec, no? > > > > > > Could this somehow be amended on to the UEFI Specification version 2.9 > > > change which added all of the unaccepted memory features? > > > > > > > Why would this need a change in the EFI spec? Not every EFI protocol > > needs to be in the spec. > > My EFI knowledge is shallow. Do we do this in other cases? > The E in EFI means 'extensible' and the whole design of a protocol database using GUIDs as identifiers (which will not collide and therefore need no a priori coordination when defining them) is intended to allow extensions to be defined and implemented in a distributed manner. Of course, it would be fantastic if we can converge on a protocol that all flavors of confidential compute can use, across different OSes, so it is generally good if a protocol is defined in *some* shared specification. But this doesn't have to be the EFI spec.
