From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (NAM11-BN8-obe.outbound.protection.outlook.com [40.107.236.65]) by mx.groups.io with SMTP id smtpd.web09.3504.1621974793318521970 for ; Tue, 25 May 2021 13:33:14 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@amd.com header.s=selector1 header.b=Pjzze0YH; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: amd.com, ip: 40.107.236.65, mailfrom: thomas.lendacky@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NYQHAXE04x8fkK1c8TKF7tSy4bGf6fO9WINnynsTPQ+tSAYxXLY99yNKxYcCzURyhjHDRHaiOIheTzRnB4IPNHVQK+1AvjYNNism/yb92cBhl0pHNGzShDd4Xk9Naq1+C1Nl7MmRgaQiScGEuD4yJnKppj4WMNi0Vpl22wGU802e5cZ2yuCXSxEJQk0NqWlMEo2mxDWi3TsJgkeZEIuPZWGjuktGKjRwsgoI3T4JzX6QFGTbkGTI+JSd9gNWyO3Tp6g+RzttZuBfUYtAppExX9P+is60Mlu4A67BukRii2tjFAfPure9w0dg05/34BFkO9GK12rpU6JlbNdhNRzJzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4WT3Z3AqIT+svCFIg5BQq2+2w13NTnTKYM2BNowrIlU=; b=VYxXlE0B4zorABDlf1tpr7UwtlX35WLUJXkopuRlne6NQBVB0OU7hQh4yi4NjLKf1ofgcLfYnuTx+9L6xUb6MDQq4PMnzfb88SdXZQqfDjY3G0h0f9j8lVsaAQ/YatArm/Tq4lNdMC6hKhCHCGPHWBQKi0eX2ZSpkvc1KBvm7IdszT5nIl62FlnpEMThWIN3nFNTIQW3tUy/XxT7rNJkMsOOaN2j8sE080UKQi3rz9Vz+FXA9P2oRN5BXqJnm9tWZAzukowbQev8uH4u/DJgpsnv4e3OMYKmePIAhJ0dsiFOA3ievVHsQLESybyVSoG3Bk2MxdZVXaqCADwr1Por5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4WT3Z3AqIT+svCFIg5BQq2+2w13NTnTKYM2BNowrIlU=; b=Pjzze0YHJa7z5o6Lh9TUsFEHIGWeRHcP7T53aDupifYPDVxZE3W3Hm9Y7so6dcKN5EUPxv1seu37kkHitVjVGE5TkuXjsbb7+MC7Pj5Wjt4Xk3tJ+CsbGyZf3eCz7mR75Ge/GJPRlKPbQaiOY15ijGU5mpqKk692+kkhYxNESyE= Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=amd.com; Received: from DM5PR12MB1355.namprd12.prod.outlook.com (2603:10b6:3:6e::7) by DM6PR12MB4433.namprd12.prod.outlook.com (2603:10b6:5:2a1::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.27; Tue, 25 May 2021 20:33:11 +0000 Received: from DM5PR12MB1355.namprd12.prod.outlook.com ([fe80::b914:4704:ad6f:aba9]) by DM5PR12MB1355.namprd12.prod.outlook.com ([fe80::b914:4704:ad6f:aba9%12]) with mapi id 15.20.4150.027; Tue, 25 May 2021 20:33:11 +0000 Subject: Re: [edk2-devel] [PATCH v1 0/8] Measured SEV boot with kernel/initrd/cmdline To: Dov Murik , devel@edk2.groups.io, brijesh.singh@amd.com Cc: Tobin Feldman-Fitzthum , Tobin Feldman-Fitzthum , Jim Cadden , James Bottomley , Hubertus Franke , Laszlo Ersek , Ard Biesheuvel , Jordan Justen , Ashish Kalra , Erdem Aktas , Jiewen Yao , Min Xu References: <20210525053116.1533673-1-dovmurik@linux.ibm.com> <8b966d52-f207-b747-96a7-2ed6f29aa432@amd.com> <21593112-ea9c-8cd1-7cad-6fc6d9645242@linux.ibm.com> From: "Lendacky, Thomas" Message-ID: Date: Tue, 25 May 2021 15:33:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 In-Reply-To: <21593112-ea9c-8cd1-7cad-6fc6d9645242@linux.ibm.com> X-Originating-IP: [67.79.209.213] X-ClientProxiedBy: SN4PR0501CA0146.namprd05.prod.outlook.com (2603:10b6:803:2c::24) To DM5PR12MB1355.namprd12.prod.outlook.com (2603:10b6:3:6e::7) Return-Path: thomas.lendacky@amd.com MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from office-linux.texastahm.com (67.79.209.213) by SN4PR0501CA0146.namprd05.prod.outlook.com (2603:10b6:803:2c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.20 via Frontend Transport; Tue, 25 May 2021 20:33:10 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 69d7d89a-9dfa-4189-aa52-08d91fbc503e X-MS-TrafficTypeDiagnostic: DM6PR12MB4433: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NPmq9j+cYF+BgSSc2Bm5eFqI4GWz93w3o5RoGcAG9MBdk1Xcy6fFSmQW3WLHqP+IO/R2NdJq56nDNu34TkN7pYNajJQoWMjwgEXeFBCF0Nky1DzJT8BbUiyngN9UvYPuNt6+b/qPpkJjQDegDMJ7JaEwsLkenEpc+45eLMgOk51hw51rfXp/kOuyJWpOOb8VzYoQyrzYNLBB3M1i8p/oiabYusFnPkdZtV0ZpqPXejyXt08XDfuixqTTClbWrf4QNpayTi10IyWxINOE4j2hOwlOrYq6OSg9ac98IEzakVZuUIiz9SLEF1UXBVeODzSKxjB/WZ8Fgt3FEsnXYyCeTRfRrJxHNiaaxPgaFRsDPsAFpRcHiYhwMwGs9mMCNWDrsgXb64DEAhvf+KIX1FqYUh2uGAlSbydZs7lUOVGQnpp5ipCWyOMUqh8phqZrLxaqdhTyJ5c+mNaUKKyIf+Z8Zbrdph+f19RsX4cue3L7jiC2nrVIdpsTkXsADZmFpJYR1lPKpNf5B4RJUNerg4xeL5djwd3nhOJkHFejszk5Jy6/KmtTQ4+3lxCBV08Kiv8IHl9tijocFMB51W4s7jgATv8anxBC/SHTb48clk3idaUaj5GOcZaee22I6tCGiYbG2j+OWuwKHl6TU/mdElySxULYtFZcadY82whUt2horapDiE3YZcDnmsqeAHe3aS13 X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM5PR12MB1355.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(396003)(39860400002)(376002)(136003)(366004)(346002)(6506007)(83380400001)(53546011)(4326008)(54906003)(86362001)(6512007)(26005)(8936002)(478600001)(16526019)(6636002)(186003)(31696002)(66556008)(316002)(66946007)(66476007)(7416002)(8676002)(5660300002)(38100700002)(36756003)(6486002)(2616005)(31686004)(2906002)(956004)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?RVdwNGtYZFR6QXZaTEJBWWp5U2E5NW5qaWUyOU1LRFF1U0tFUUZkUVRoUUta?= =?utf-8?B?Z0VoSHVOVzdvbFJmWnYyWWtIOCtNWHNUYjZPNEs3NXZrYnV6bFpOZjR0WlQ3?= =?utf-8?B?OUQzakMxbitIaS9yQXZYNWNBVHdkOC9zUkdTc3g5NGM1OFJoSlU2Qm0rbmY1?= =?utf-8?B?NkJLRXJMRjBPcDBmTVViZExDTHZhZW5NNjhNWWptaEl0bEsxTS94NklCclA3?= =?utf-8?B?QXpHQktEbUZqdTJiR3h5YVJGNjVrb2Y3MHVtWjJIUHJzYkZrU0NIeW51djhI?= =?utf-8?B?RXBLY1dlWWRlT3ZsRFJSSjdpZDc1OEh0VGkxRTRNdTAxV0dHKy9RTlpBRklz?= =?utf-8?B?THdKSURjUVBJb3hIWjBEU0ZQTFEzTDkzVDRhUGRPRDg2blRwa252cHh0NXIw?= =?utf-8?B?VDBvc2dxbFkvTmwzZ0NvZ25oaThoNGRPbzNxM3dnZjZ0ei9TZ044ZmVSU3ZR?= =?utf-8?B?eVZkdVZUeFk2RUpKbDJoSDA5Wmh2cGtOMHlXZm9paFZ6MFlXL2ZkVmhnZWs2?= =?utf-8?B?VEdmVjBKaDRvVG9YSHd1d2FUTlBIc29VMTk3eVRRdHNuQXNkOVFvWkJNd05j?= =?utf-8?B?QTFNMGlaQ0Vvck9ZK0F5SDRnU3N5TGdQY0djaHp4dWFlYlNDb1BBNFdwUlhh?= =?utf-8?B?ZmlENHV4VkVlZnpNdXE3Uml2bkIzRG1DMnZyMlF2VVRqUzhuQm1mWVdZZHQx?= =?utf-8?B?QkozL1UrTTBuZ0R2aGx2Ulpacmx3Tnd5bjRaMWl1cFNZZjRsa3JBWHBKN2sy?= =?utf-8?B?ZVNiS2ZHYVFZMVRBS1dkOUdJR2FJdDRZb0FoQ2JKaDI0WWhUWEM3T0p3K092?= =?utf-8?B?cm9TcFVqTVI4M09NTWtrOXdiTVZnbHNTaWlzNUNYcy8xWTd5QmhnWDdnKzV4?= =?utf-8?B?cUhET0ZGd20wN0pTN2N5ZktRbGVIb3ZMSnRtMkh4MEJFK2xCb1lHTFVoYVZO?= =?utf-8?B?NlFJWVViU3JvUGlNK1lYUTdKalFuVU9ucHFqRklnc0lvOGc1alVuSUlKMk1J?= =?utf-8?B?ZUIyZkw5QWhNV0NkWkJYTUlpMXprS1hLYkxxV1l1eC9YSDBxMTFrS0R6V3BU?= =?utf-8?B?VTkzQlRaWnB2anhWekxNbDZFWUZuWXlYSDh2bkszTkNPdGpJS2hkR0R1b3oz?= =?utf-8?B?ZEQ0eHJyWC9XbXpRRjZBSWw4aXRPZllwYjB5ZmJqYVl5bUthT2ZQbXVmOHp1?= =?utf-8?B?ZzFEMUM3RmNncS9WRDRuMGJUME9CWDhOZWozNVF5bzRMRWZERDU5MTZkZ1V2?= =?utf-8?B?U2xhNUhXQUxBa2VBNk5lZjFZVkJsNVU1QTRWdno4MmE2Vm9HbGpSaklEdEFu?= =?utf-8?B?Tyt2L1NBTk00amZ4aTdNbjgvcC9nOWVzc3FuSHZJaFNTM2hJSUdCYWJiaHRL?= =?utf-8?B?QlBQZWFCVXhqcWVQeUJZY1lHdVhhU0ZkeXBKdk5pdWZmTXFaWmpsWk5zSFAw?= =?utf-8?B?RHBLYVFIcHdhb0duRVdnQXRhZ0lmcmpyS2UzVytjOE5yNjNEaGFmMkVQdlg5?= =?utf-8?B?MklrUURQbkcxMHo0emUrYm9OL1NyM0pDWGt3d1E0bUp0aG81VlRvT1NVWHFY?= =?utf-8?B?WGM1L29nZGFDQU9xdkRBMDJhSnlJSWxOZU1JVExtSWJjWjBQRUhYV2k2dDhS?= =?utf-8?B?eVdSMjdwL1BQVWR5V3JoUkU5Zk9iU1pDL3ZvbmZPYmVJL2NsYjczdjByNXAz?= =?utf-8?B?alZJdmQ0aVl1NW5Qb2c5OU4xNEI5UFQrR1JjaXkrQWlDa05Renp3YmlyVU5s?= =?utf-8?Q?E8VBYcdXXjAC5inElluHcYDkVGN9eqbDLijB4rY?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69d7d89a-9dfa-4189-aa52-08d91fbc503e X-MS-Exchange-CrossTenant-AuthSource: DM5PR12MB1355.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 May 2021 20:33:11.2941 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: wqjkyUWKOpU4SHRB0xFG8savCdJr+tXhkpxr3m3sfZoXQwI6MBp6ApT+cQLGM0fxRFwS1eKsbSBeO8sp351gyA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4433 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 5/25/21 3:08 PM, Dov Murik wrote: > Hi Brijesh, > > On 25/05/2021 18:48, Brijesh Singh wrote: >> >> On 5/25/21 12:31 AM, Dov Murik wrote: >>> Booting with SEV prevented the loading of kernel, initrd, and kernel >>> command-line via QEMU fw_cfg interface because they arrive from the VMM >>> which is untrusted in SEV. >>> >>> However, in some cases the kernel, initrd, and cmdline are not secret >>> but should not be modified by the host. In such a case, we want to >>> verify inside the trusted VM that the kernel, initrd, and cmdline are >>> indeed the ones expected by the Guest Owner, and only if that is the >>> case go on and boot them up (removing the need for grub inside OVMF in >>> that mode). >>> >>> This patch series declares a new page in MEMFD which will contain the >>> hashes of these three blobs (kernel, initrd, cmdline), each under its >>> own GUID entry. This tables of hashes is populated by QEMU before >>> launch, and encrypted as part of the initial VM memory; this makes sure >>> theses hashes are part of the SEV measurement (which has to be approved >>> by the Guest Owner for secret injection, for example). Note that this >>> requires a new QEMU patch which will be submitted soon. >> >> I have not looked at the patches, but trying to brainstorm if we can >> avoid reserving a new page in the MEMFD and use the existing EDK2 >> infrastructure to verify the blobs (kernel, initrd) loaded through the >> FW_CFG interface in the guest memory. >> >> If I understand correctly, then in your proposed approach, guest owner >> wants to ensure that the hypevisor passing its preferred kernel, initrd >> and cmdline. The guest owner basically knows the hashes of these >> components in advance. > > Yes, that's correct. > >> So, can we do something like this: >> >> - The secret blob provided by the guest owner should contains the hashes >> (sha384) of these components. >> >> - Use openssl API available in the edk2 to calculate the hash while >> loading the kernel, initrd and cmdline. > > Indeed we do something similar already - we use Sha256HashAll (see patch > 5 in this series). > > >> >> - Before booting the kernel, compare the calculated hash with the one >> listed in the secret page. If they don't match then fail otherwise continue. > > That is indeed what we do in patch 6 (the calls to our ValidateHashEntry). > > >> >> Did I miss something ? > > Thanks for proposing this. > > Your approach has the advantage that there's no need for extra > pre-allocated MEMFD page for the hashes, and also it makes the QEMU flow > simpler (QEMU doesn't need to compute the hashes and put them in that > special MEMFD page). I think that the only change we'll need from QEMU > in the x86_load_linux flow (which is when the user supplies > -kernel/-initrd) is that it won't modify any memory in a way that the > modifies the hashes that Guest Owner expects (for example, avoid writing > over the kernel's setup area). > > However, the disadvantage is that it unifies boot measurement with the > secret injection. The Guest Owner _must_ inject the hashes, otherwise > the system doesn't boot; whereas in our current suggestion the Guest > Owner can check the measurement, verify that everything is OK, and just > let the guest continue. > > But as I write this, I think that maybe without secret injection the > guest is not really secure? Because the host could just continue > execution of the guest without waiting for measurement check... If the > Guest Owner _must_ inject a secret for SEV to be secure in any case, we > might as well choose your path and let the Guest Owner inject the table > of hashes themselves. > > I'd like to hear your (and others') thoughts. Brijesh and I had a long discussion over this. I think that if you're dealing with a malicious hypervisor, then it could, in fact, measure all the components that it wants to be used and, using LAUNCH_UPDATE_DATA, add a page, that matches the format of the guest secret page, to the guest and indicate that page as the guest secret. Even though the measurement would fail validation by the guest owner, the hypervisor could ignore it and continue to run the guest. So you need something that proves ownership of the guest secret - like a disk key that would fail to unlock the disk if the hypervisor is faking the guest secret. Does all that make sense? Thanks, Tom > > -Dov >