linux-kernel - Re: [PATCH Part1 RFC v3 20/22] x86/boot: Add Confidential Computing address to setup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210625181417.kaylo56pz4rlwwqr@amd.com>
Date:   Fri, 25 Jun 2021 13:14:17 -0500
From:   Michael Roth <michael.roth@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Brijesh Singh <brijesh.singh@....com>,
        "Kuppuswamy, Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        linux-efi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        linux-coco@...ts.linux.dev, linux-mm@...ck.org,
        linux-crypto@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
        Tom Lendacky <thomas.lendacky@....com>,
        "H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Sergio Lopez <slp@...hat.com>, Peter Gonda <pgonda@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        David Rientjes <rientjes@...gle.com>, tony.luck@...el.com,
        npmccallum@...hat.com
Subject: Re: [PATCH Part1 RFC v3 20/22] x86/boot: Add Confidential Computing
 address to setup_header

On Fri, Jun 25, 2021 at 07:01:54PM +0200, Borislav Petkov wrote:
> On Fri, Jun 25, 2021 at 10:24:01AM -0500, Brijesh Singh wrote:
> > In the case of EFI, the CC blob structure is dynamically allocated
> > and passed through the EFI configuration table. The grub will not
> > know what value to pass in the cmdline unless we improve it to read
> > the EFI configuration table and rebuild the cmdline.
> 
> Or simply parse the EFI table.
> 
> To repeat my question: why do you need the CC blob in the boot kernel?

We basically need to be able to access the CPUID page in any place where we
might need to emulate a cpuid instruction, which both the boot kernel and
proper kernel do very early on for things like probing paging support and
checking for SEV/SME features.

> 
> Then, how does it work then in the !EFI case?

Currently, based on your v3 feedback, I have the following order of
precedence for getting at the cc blob to get the cpuid page:

For boot/compressed kernel:

  1) Search for CC blob in the following order/precedence:
     - via linux boot protocol / setup_data entry
     - via EFI configuration table
  2) If found, initialize boot_params->cc_blob_address to point to the
     blob so that uncompressed kernel can easily access it during very
     early boot without the need to re-parse EFI config table

For uncompressed/proper kernel:

  1) Search for CC blob in the following order/precedence:
     - via linux boot protocol / setup_data entry
     - via boot_params->cc_blob_address

So non-EFI case would rely purely on the setup_data entry for both (though
we could still use boot_params->cc_blob_address to avoid the need to scan
setup_data list in proper kernel as well, but scanning it early on doesn't
have the same issues as with EFI config table so it's not really
necessary there).

I opted to give setup_data precedence over EFI, since if a bootloader goes
the extra mile of packaging up a setup_data argument instead of just leaving
it to firmware/EFI config table, it might be out of some extra need.  For
example, if we do have a shared definition for both SEV and TDX, maybe the
bootloader needs to synthesize multiple EFI table entries, and a unified
setup_data will be easier for the kernel to consume than replicating that same
work, and maybe over time the fallback can be deprecated. And containers will
more than likely prefer setup_data approach, which might drive future changes
that aren't in lockstep with EFI definitions as well.

It doesn't matter much currently though since setup_data is basically just
pointing to the CC blob allocated by EFI.

> 
> The script glue that starts the lightweight container goes and
> "prepares" that blob and passes it to guest kernel? In which case
> setup_data should do the job, methinks.

Brijesh can correct me if I'm wrong, but I believe that's the intent, and the
setup_data approach definitely seems workable for that aspect.

> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.kernel.org%2Ftglx%2Fnotes-about-netiquette&amp;data=04%7C01%7CMichael.Roth%40amd.com%7Cf927ef94d7af4819892708d937faf24b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637602373266379986%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=t5iRKv6RcaPazLlON1oGyyEZdxX%2FAxZz8cjJwrz7UqQ%3D&amp;reserved=0