On Tue, Jun 28, 2022 at 07:17:00PM +0200, Ard Biesheuvel wrote: > 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. I've talked with our firmware expert today and I think we have a problem with the approach when kernel declaries support of unaccepted memory. This apporach doesn't work if we include bootloader into the picture: if EBS() called by bootloader we still cannot know if target kernel supports unaccepted memory and we return to the square 1. I think we should make it obvious from a kernel image if it supports unaccepted memory (with UTS_VERSION or other way). Any comments? -- Kirill A. Shutemov