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.69]) by mx.groups.io with SMTP id smtpd.web10.19958.1605449314769148318 for ; Sun, 15 Nov 2020 06:08:35 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@amdcloud.onmicrosoft.com header.s=selector2-amdcloud-onmicrosoft-com header.b=CPROjeX+; spf=none, err=SPF record not found (domain: amd.com, ip: 40.107.236.69, mailfrom: brijesh.singh@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dXgD5uByFs4K4g6Q3OaPDC/c0Oqsikpakqrm9RMuZVjZ90rB6U7QP049UOZWnQsRmKbifvHqFEmXj76RiZUKVniAZR2eBYmH96RTSmZwWhj+GKdUOZUdArf+jagB1xh0qKiTICSEaDmg9JnbVAzNpwDSnen2/hwWRaQn3Reh4eVMINaqdugOOhiJTKTTHIUA3TbXl6KDG6OvCXJrlLRzRWixsb19x8i8qj1xRfQjIPyjaDCK3tjAjuIhqJcX82rU23FQ04Z2RzvYhNFb5WPvjYx/tLlxUaIe2OSEPn5T9FAMh5+xmnqgJ16hjc04PKMXESR4UVfbBzdzw3ntx6KeBw== 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=XUxIX6C4iXumlO7kaF4G7QG7Eer9faioEO3EkRkmO0A=; b=JcyChElWT7oKUpJVLtzC82KeYKXASuHwx+5Wbm7zciCA+ID7y4q6z+ZU8JLNzy9S8sybkguXu/zKuDuQ2t/RmMW4x0X/cbodfM8xonGVdfLI506aNWy85+C3EIKCmSIpOZeADF8jGFz2INSyqLt22gr68n46u9DvzvDJXS/ISkWZD0C87MKNHAaoLF5QRv7ESWkIuBAHgLdaSG75k0LTDcDYqnBIXx41XihyBW6plIp1+FtHPG56LRVYAvB7kVo+y9M606fOFxDZvQMAlsvQ9qeoMYpQDMqVrlIyRZAwNCWZb6RPZZ58OKeDv8DHWaNH1/moTgqYAD4libo01AN3Ow== 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=amdcloud.onmicrosoft.com; s=selector2-amdcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XUxIX6C4iXumlO7kaF4G7QG7Eer9faioEO3EkRkmO0A=; b=CPROjeX+I85Fnra8N/9GBqNPCAs9tQ9Xg3j7Kmu2HpY/G4Qc8acoy258FxNtJTd/zQoq09Ol/7sWwVj48MDVHXexa6YeCLPqBvD4s9bsiojrJBQyEFvc6Ug9n3Ip049VN/qqk//JctSCbtr3/EMnmVod+j2V7SdkCwc4UWFT/ZU= Authentication-Results: us.ibm.com; dkim=none (message not signed) header.d=none;us.ibm.com; dmarc=none action=none header.from=amd.com; Received: from SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) by SN1PR12MB2448.namprd12.prod.outlook.com (2603:10b6:802:28::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Sun, 15 Nov 2020 14:08:32 +0000 Received: from SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::18a2:699:70b3:2b8a]) by SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::18a2:699:70b3:2b8a%6]) with mapi id 15.20.3564.028; Sun, 15 Nov 2020 14:08:32 +0000 CC: brijesh.singh@amd.com, devel@edk2.groups.io, dovmurik@linux.vnet.ibm.com, Dov.Murik1@il.ibm.com, ashish.kalra@amd.com, tobin@ibm.com, david.kaplan@amd.com, jon.grimm@amd.com, thomas.lendacky@amd.com, frankeh@us.ibm.com Subject: Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf To: jejb@linux.ibm.com, "Dr. David Alan Gilbert" References: <20201112001316.11341-1-jejb@linux.ibm.com> <5cb9e43e-b22f-0ffc-3b02-1b173454de9f@amd.com> <20201112193804.GJ2905@work-vm> <5890c3a4-a480-0ca7-55fd-550a91d8ecb1@amd.com> From: Brijesh Singh Message-ID: Date: Sun, 15 Nov 2020 08:08:30 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 In-Reply-To: X-Originating-IP: [70.112.153.56] X-ClientProxiedBy: SA9PR13CA0031.namprd13.prod.outlook.com (2603:10b6:806:22::6) To SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) Return-Path: brijesh.singh@amd.com MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from Brijeshs-MacBook-Pro.local (70.112.153.56) by SA9PR13CA0031.namprd13.prod.outlook.com (2603:10b6:806:22::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.15 via Frontend Transport; Sun, 15 Nov 2020 14:08:31 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1955d012-f7d3-4bc7-6a68-08d8896fef68 X-MS-TrafficTypeDiagnostic: SN1PR12MB2448: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vIDOd/J57Nerq053z1L6G4R5FBCFhupEVQdSxK3YZ3YQig+ahM5sSYQbt2LvYTB7dKUYmtbwUElIyg6BjUxINNRvf1GpaHmrOI/eUsop4DSbBYgrrHNucmwJbWaEnVkHNMgoe/CK8klO1HViGZFEh3YDan1l06sKSlOZ62Dxy4mo8sHUNJ30y8VMC1xuiVkH0LnSoTjelMlL+jIfxEXWNpgztxG6Qc5H0jm8MSwFwVVYYxapzOeCQl0zs80/q2YNjj8wEiPEJoBg0Eq9W2MaQOCxnl+u4mnwaJvUSB6slm1yT0EhArmEZSS4OKv713dLJ3+zkLwiPPpgGgYQY1bNN0q0FmhsfZKeBqCcCKjtIkzhRi19Bxl+be8u6h8G/+X1 X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SN6PR12MB2718.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(39860400002)(346002)(136003)(366004)(376002)(396003)(2906002)(53546011)(6506007)(36756003)(52116002)(83380400001)(31696002)(31686004)(26005)(6916009)(44832011)(186003)(16526019)(4001150100001)(478600001)(2616005)(956004)(316002)(4326008)(8676002)(5660300002)(6486002)(6512007)(8936002)(86362001)(66476007)(66556008)(66946007)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 3nGTmbpadmrZ+T5tMwjEuzjhXV2QUHmbdvqhC24MVGfbXXdwVLvNbLqLJipmfDZnG9PEsPWWVVmu1qNJqWuk6JkIczqDUpMR+WZa+m1wW+M75oZYqppwvV3d5zIaP6ws6LgHhA/y6ufLW+++QCxGXiNO6BX/iFVHLSI93KjyVkO59KjAa2UCgg3Lll3GKNXL/AR4x4y9LTuT3Z0XFrfLRRvnpQJAXxGSsLdobex+hCBPbP+E8cKjVkmQsKdwN8g4tX/g8Z4ywBjmIly0vjH27ZSpKwZwyjTkaeYqxy+CYSRrqPYRsZv+0+X+6TViveCDQ/Qo+Szj+JSnLAsXyNxyguIPpo2vPxJNbZOOtu4oIzUD5fG53IEX2OemCUWgGYr3V+2HrLHlY6EJBGHtgyV+3jhZbZ3y9VZUw2LXDnY0FuYOPpMHrIpuQopBmop+RPl9SWLdE5D5xLTn65jOjrmDS0QBujvLcYYWdPSKimIqofut2R+bgog+QGJI3lEDdzeLZxlXUQ0PQSHTgWywr0X14YfH1kZxWlm7/HaOmWWrazJfjbiZ0iWsDFIsVE2bmTRs9sNQ771WYMAjeVZN4eXDm5Gp7/JkIx/IYsaDPGJk1IyME5ZTuIkRBwjf66O2bOIAFigwoqD7xAHlY7o93ENnnw== X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1955d012-f7d3-4bc7-6a68-08d8896fef68 X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2718.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2020 14:08:32.5467 (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: kv7lBL6QAH1b0eQlkW7Km7EafuGJgicgm9g9ofWoYeGS6pU7H/kQ4kVPUDPoWMN8HATjiKb+hYfJZbn2Z26W+A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR12MB2448 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 11/12/20 4:50 PM, James Bottomley wrote: > On Thu, 2020-11-12 at 15:56 -0600, Brijesh Singh wrote: >> On 11/12/20 1:38 PM, Dr. David Alan Gilbert wrote: >>> * Brijesh Singh (brijesh.singh@amd.com) wrote: >>>> Hi James, >>>> >>>> Thanks for series, I glanced at it, the changes looks okay to me. >>>> I have one questions. >>>> >>>> How does the grub locate the disk decryption key ? Am I correct >>>> in assuming that the gurb is iterating through a configuration >>>> table entries and comparing the Secret GUID to locate the secret >>>> key. As per the SEV spec, its possible that a guest owner can >>>> call the secret injection more than once. I don't see the patch >>>> consider that case, should we support this or limit to one >>>> inject?=C3=82 Maybe Qemu can enforce this property. >>> That's interesting, I hadn't realised that was possible - however, >>> I can't see a way to use it - for it to be useful, you would have >>> to have a way for the guest to communicate to the owner that it had >>> finished with the first injection and would like the next; but if >>> you already have a way to communicate from the guest to the owner >>> to request stuff, then you could pass a new secret by that comms >>> route? >> The main reason for its existence was to allow guest owner to inject >> multiple blocks of the data if they need to do so, e.g IIRC, Enarx >> folks use this to inject the keep which is much bigger than 128K. > In some ways this sounds like the wrong approach. I mean we could use > injection to inject the entire VM image as well, but we don't, we > inject the key and decrypt the image ... it does rather sound like > that's what should be happening for other bulk data, like the keep. If > you do it this way you can use the main CPU and bulk memory encryption > to pull the data into the secure memory rather than using the PSP, > which is a lot slower. I wanted to highlight spec. I agree that in our VM launch I don't see a need to provide a multiple LAUNCH_SECRET as long as we define producer and consumer format to package the multiple secrets in one inject. > > Also one of the problems with having OVMF define the secret location is > that we have to find space in the MEMFD. For a single page like the > current implementation uses, that's easy, but for tens to hundreds of > pages it would be impossible. Even if we guid describe everything, > standard aes keys are 16-32 bytes, so even in the worst case we can fit > 85 guid described decryption keys in a page, which should be more than > enough for anyone, provided we inject the key to the bulk data, not the > bulk data itself. >> I am not sure if we really need it for the VM boot flow but we >> probably need to define the secret page layout such that it contains >> multiple entries in it. In our case the Secret can't be more than a >> page, so, we can define a secret page layout such that it can contain >> more than one disk key. I was thinking about something like this >> >> typedef enum { >> >> DISK_KEY_AES_128, >> >> SSH_PRIVATE_KEY, >> >> ... >> >> } data_type; >> >> struct secret_data { >> >> u8 entries; >> >> struct { >> >> data_type type; >> >> u16 len; >> >> u8 name[16]; >> >> u8 data[]; >> >> } entry[]; >> >> } >> >> This should allow us to package multiple secrets in one inject. > I proposed something slightly different in a prior email. If we use > the guid approach, we don't have to define the data structure a-priori > ... just the producer and consumer have to agree on what it is. Yes, your guid approach is much preferred. thanks > >>>> Do you see any need for the Linux kernel needing to access the >>>> secret? Since the secret blob is available through configuration >>>> table, I believe we can have a platform driver that can read the >>>> configuration table and retrieve the secret blob. >>> I guess it depends if you get the Grub to pass the fs secret down >>> to the kernel or let it pick it up itself from the same place. >> I guess the main reason why I was asking this is, what if guest owner >> provides more than one disk keys in the secret injection blob. Grub >> can use the boot disk key to access the Linux images and other disk >> keys may later be used by Linux. > Right, see other email for limitations. > > James > >