From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2927133CC for ; Mon, 18 Jul 2022 17:21:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658164918; x=1689700918; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=XQ2y1/VlwCd334Ie2B6PhFqb8Le129sl7rpEk9foass=; b=gAgSRBCQzzC9j6cR1plmLy25MLLwlDHshlQkliuOVHmulqpCPxO/GGot GG1BGDdK5kOIrTgunO2N3h+DNnk+UORdAkj+O3BCh81jBOHcF29dHPldE 9xwHneDrSpCDqYviA4AryTwUUtU2wkgt4v8clTUa2avcoYCfeXMshE/kZ WESbclShyltkm4vn3PxB7B9BXhvskxjr9v2kE+9ytYYu/OXN8G4Jfafkm 6hYvnhYe2H1wgreWmL83Uo5ABN3dcJ3OkaZuBFDcjAX8UaIshZGT6p+hX dC6c5oAde3HPVpyfqjh2rCJlKNwbnZOIshAZBVzn0O7zeOmRluCChWFE9 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10412"; a="350235844" X-IronPort-AV: E=Sophos;i="5.92,281,1650956400"; d="scan'208";a="350235844" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2022 10:21:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,281,1650956400"; d="scan'208";a="655374923" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga008.fm.intel.com with ESMTP; 18 Jul 2022 10:21:50 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 4FE9410E; Mon, 18 Jul 2022 20:21:59 +0300 (EEST) Date: Mon, 18 Jul 2022 20:21:59 +0300 From: "Kirill A. Shutemov" To: Ard Biesheuvel Cc: Peter Gonda , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Dave Hansen , Mike Rapoport , David Hildenbrand , Marcelo Cerri , tim.gardner@canonical.com, Khalid ElMously , philip.cox@canonical.com, the arch/x86 maintainers , Linux Memory Management List , linux-coco@lists.linux.dev, linux-efi , LKML Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory Message-ID: <20220718172159.4vwjzrfthelovcty@black.fi.intel.com> References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220627113019.3q62luiay7izhehr@black.fi.intel.com> <20220627122230.7eetepoufd5w3lxd@black.fi.intel.com> <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Jun 28, 2022 at 07:17:00PM +0200, Ard Biesheuvel wrote: > On Tue, 28 Jun 2022 at 00:38, Kirill A. Shutemov > 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