From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (NAM10-BN7-obe.outbound.protection.outlook.com [40.107.92.46]) by mx.groups.io with SMTP id smtpd.web08.14683.1605814900670058960 for ; Thu, 19 Nov 2020 11:41:40 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@amdcloud.onmicrosoft.com header.s=selector2-amdcloud-onmicrosoft-com header.b=hV3zZ7zA; spf=none, err=SPF record not found (domain: amd.com, ip: 40.107.92.46, mailfrom: brijesh.singh@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oeFKv42IR4RhDVf+uPLyO3TYAISx2621m/bgcRlabTXLQ2KLBIrupTS6/P4b5wHTNIHTP2Cu/cFdKYPT+KO80nLiLtIKNEMjgeT18i03lIndmjhA+Y1MaQnX9VqtUucNwHwyi7ht0qARLC1AEMJ6EhOhpxmUTi08jVPxwanra9sZ0hQ/oNmn5TKNaz2Kqzo+Ne3hc/8N09uFddOvlzC+34nw83bqHZkge7ee9dYOtojxNmgbIzUP2n/Zou1Uy0QnE3J6CWtFpT7C27bHSohYS6rNnibw3FT0uqSfriCsrmqvN3rwn2OSIqppZ+UgmcXyY6xirHbBvpqFsyVniFkDLQ== 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=pUr7Y4/d6FT9vr7cfTf6rquF3963f5hQn5JSgEwKVuE=; b=kHrhMNAVDywifnb3xp0gd9kwnNm2ZWXKhktCOaE2q54Uym3wZZbFxDiy4NKyT4op4axWotWNmawEKldKqC0YVT9qymGE6CFCaLrjIk7CmnisH8hvYnlEyuONjWchZjpB7Hn6dMpA19NEkZ9UvLMwB+v91fBhmGf47++O0Kp9Zq9OtZ2iCc9m8nKl8twyMfzQ04xsFwmU50vFhHfZE815a3Ge/d35nccGr2WkDV8naKkBwcTIWBCYO+B0kxZPBDuUmE0e6X/SOlbm6CiGwodiBLTH5ObBSKXwyPPPz7qANT9+8Sdv5Dol38W0ZD16YzLwHu2uE5u8kVJHLQpINLfApQ== 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=pUr7Y4/d6FT9vr7cfTf6rquF3963f5hQn5JSgEwKVuE=; b=hV3zZ7zABKZLzvw2zzJYOFjP/EDoms7rO9Gmj9hvWrvPfgO6DlIZ/U9xNi43W5y7+yPYPTFGYVlUs8vYMXzNPtdintqeacH84TPEeQZI3GwcXtEchh+jgop/f/1Y+3IFZO+wpEg9nHxpkm5nPSN30AfO6G4sL1GUH0osrP31Vbk= Authentication-Results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=amd.com; Received: from SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) by SA0PR12MB4495.namprd12.prod.outlook.com (2603:10b6:806:70::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.28; Thu, 19 Nov 2020 19:41:38 +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; Thu, 19 Nov 2020 19:41:38 +0000 Cc: brijesh.singh@amd.com, 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, "Dr . David Alan Gilbert" Subject: Re: [edk2-devel] [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd To: Laszlo Ersek , jejb@linux.ibm.com, devel@edk2.groups.io References: <20201112001316.11341-1-jejb@linux.ibm.com> <20201112001316.11341-4-jejb@linux.ibm.com> <6db69ccd-340f-2df2-718b-5f7db09da0b8@redhat.com> <111856145fea09b5ed88a1dfa7b7d7ff6eece639.camel@linux.ibm.com> <0576e9ad-e844-c50a-a329-ba19138b587d@redhat.com> From: Brijesh Singh Message-ID: Date: Thu, 19 Nov 2020 13:41:36 -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: <0576e9ad-e844-c50a-a329-ba19138b587d@redhat.com> X-Originating-IP: [70.112.153.56] X-ClientProxiedBy: SA9PR13CA0002.namprd13.prod.outlook.com (2603:10b6:806:21::7) 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 SA9PR13CA0002.namprd13.prod.outlook.com (2603:10b6:806:21::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.13 via Frontend Transport; Thu, 19 Nov 2020 19:41:37 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 82365374-9f28-4036-938c-08d88cc321b0 X-MS-TrafficTypeDiagnostic: SA0PR12MB4495: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4dfEZ+4H9Gj+xL0gEL985CJbQf8NJTgg3A0NmCPDWsE5To90mDyRVMwAWQvbVXgHG2v2yM/asBSxnXLn/P/nR6SCHN+4Z6v1O3PLnUhXIEbiWirwqX/or0xUNyNbmZQQn2j50H5a1GrThSDhEXGtA44tTCvh9RfNWwj/L7/6QwJ+bw3T9Omv4VqKYot9dGT+IKWcTFdS7xLYHJRzlF9rFZGbeni5vsTBLs1gItuAdZYjRdjy1bYe9mwrQ9oZn+sSSKkQrlpWgCYVmMx+MBTE5dTdjVEd/ee7gy2jJwX6/4yk3zPI8ch/6wB64RkZJtdoxPPP8vcw9Fhl6HNzjJesgmKYwGnRKP39euPTDgTmA07FVhKmroy51ipEJR37ei5laLXf2P8r4t9zxdvQ5d1bo5C+oe8PnQdtcMA3Q9KBLtWPRuiC3/qoD9FX2WRoO2esrv040ABdnhXDlnuOTozkNHbAo6XL9qQf74fykud8PHU= 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)(346002)(376002)(39860400002)(396003)(366004)(136003)(2616005)(36756003)(5660300002)(186003)(66556008)(44832011)(478600001)(966005)(66476007)(66946007)(83380400001)(53546011)(6506007)(956004)(31686004)(16526019)(31696002)(26005)(86362001)(19627235002)(6512007)(52116002)(4001150100001)(6486002)(8936002)(316002)(4326008)(2906002)(8676002)(219293001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: S6BJou/rJlgMSb7SMxYLyeWEO5BDlz18DSqs51GN9h/AdGt+7o+6k+xWZPq8B9dKxXXq8AUA44shIxWZ0tl2AYZGbcc3fnNIasGUqa/vfvfgZLs7LaVgd6GsgMSRgEPInerTn6mXNTDab8vIi7XuJVo9nz7t/qH426QeUd8/FvA8SQOmpMYj6FZCNisXJdPN+Q52ufqYoKytwtx7lDWdzMCvDTDoeQ4GoklpzwuH+Zj8lX7gOZ3i9ZnRb73UKkw1bQZK6eoBu/U8uoJ06DbOiT2evR0DQEeuCysmRgl2rXnNfWuzikjVXd1xZOEtLMuimSq4KEjuOAnxCqHLpePoMgk2N5xtRspid/WHlBin5zuJFGkJ3fzmGtykRdtWqk9PwRkKBRgrjCX/kiKVtwp2ZjNwyCFYfFXA4BW9lK50glv5alGRaXcvOZRwLPGnR7fU9oadFtBbceZ1XywHZ1ureGkfCGsYdMRzYy7sPZbp3hHkz4a9YTJwzqTACsyYI8piI5ABS60y75LbbutTFTzasMzZqaDZyZ8uYxglfY5HSPZDMwYm7ZKtlbEBeGOIBwHnSLNkBJKkS0H2tmrcLpfW1Xz0DGPNX3hTa/TNjvQ8I7Hz7wd7AAJ1jP9ND9QcVHmCncv3VDLtsxeypxWIs8JgfA== X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 82365374-9f28-4036-938c-08d88cc321b0 X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2718.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2020 19:41:38.7415 (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: aIXpQAyWES3sfroIeJQ0pW2B+dOICD/jCumstw+bw0/JHP97CXhMbNY61klyEquweo18kqcbU15cE4Aq9qvUoA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4495 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US On 11/19/20 1:50 AM, Laszlo Ersek wrote: > On 11/18/20 21:23, James Bottomley wrote: >> On Mon, 2020-11-16 at 23:46 +0100, Laszlo Ersek wrote: >>> On 11/12/20 01:13, James Bottomley wrote: >> [... I made all the changes above this] >>>> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>> b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>> index 980e0138e7..7d3214e55d 100644 >>>> --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>> +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>> @@ -35,6 +35,8 @@ ALIGN 16 >>>> ; the build time RIP value. The GUID must always be 48 bytes >>>> from the >>>> ; end of the firmware. >>>> ; >>>> +; 0xffffffc2 (-0x3e) - Base Location of the SEV Launch Secret >>>> +; 0xffffffc6 (-0x3a) - Size of SEV Launch Secret >>>> ; 0xffffffca (-0x36) - IP value >>>> ; 0xffffffcc (-0x34) - CS segment base [31:16] >>>> ; 0xffffffce (-0x32) - Size of the SEV-ES reset block >>>> @@ -51,6 +53,8 @@ ALIGN 16 >>>> TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 >>>> >>>> sevEsResetBlockStart: >>>> + DD SEV_LAUNCH_SECRET_BASE >>>> + DD SEV_LAUNCH_SECRET_SIZE >>>> DD SEV_ES_AP_RESET_IP >>>> DW sevEsResetBlockEnd - sevEsResetBlockStart >>>> DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F >>> (5) I'd prefer if we could introduce a new GUID-ed structure for >>> these new fields. The logic in QEMU should be extended to start >>> scanning at 4GB-48 for GUIDS. If the GUID is not recognized, then >>> terminate scanning. Otherwise, act upon the GUID-ed structure found >>> there as necessary, and then determine the next GUID *candidate* >>> location by subtracting the last recognized GUID-ed structure's >>> "size" field. >> So for this one, we can do it either way. However, the current design >> of the sevEsRestBlock is (according to AMD) to allow the addition of >> SEV specific information. Each piece of information is a specific >> offset from the GUID and the length of the structure can only grow, so >> the ordering is fixed once the info is added and you can tell if the >> section contains what you're looking for is present if the length >> covers it. >> >> We can certainly move this to a fully GUID based system, which would >> allow us to have an unordered list rather than the strict definition >> the never decreasing length scheme allows, but if we do that, the >> length word above becomes redundant. > Well, GUIDed structs in UEFI/PI are sometimes permitted to grow > compatibily, and for that, either a revision field or a size field is > necessary / used. I kind of desire both here -- it makes sense to extend > (for example) the SEV-ES reset block with relevant information, and to > add other blocks of information (identified with different GUIDs). > > Basically I wouldn't want to finalize the SEV-ES AP reset block just > yet, *but* I also think this new information does not beloing in the > SEV-ES *AP reset block*. The new info is related to SEV-ES alright, but > not to the AP reset block, in my opinion. If you read the larger context > (the docs) in the assembly source around "sevEsResetBlockStart", the > launch secret just doesn't seem to fit that. > >> I don't have a huge preference for either mechanism ... they seem to >> work equally well, but everyone should agree before I replace the >> length based scheme. > I agree we should all agree about it first. > > And, to reiterate, I'd like to keep both the length fields and the > GUID-ed identification. In other words, a GUID should not imply an exact > struct size, just a minimum struct size. I agree with the GUID based approach, it aligns well with the future needs. Looking forwardm we will need to reserve couple of pages (secret and cpuid) for the SNP. In my WIP patches I extended reset block to define a new GUID for those new fields. https://github.com/AMDESE/ovmf/commit/87d47319411763d91219b377da709efdb057e662#diff-0ca7ec2856c316694c87b519c95db3270e0cac798eb09745cce167aad7f2d46dR28 And I am using this qemu patch to iterate through all the GUIDs and call the corresponding callbacks. https://github.com/AMDESE/qemu/commit/16a1266353d372cbb7c1998f27081fb8aa4d31e9 > > Thanks! > Laszlo >