From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (NAM12-DM6-obe.outbound.protection.outlook.com [40.107.243.76]) by mx.groups.io with SMTP id smtpd.web11.59031.1674682709440461918 for ; Wed, 25 Jan 2023 13:38:29 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@nvidia.com header.s=selector2 header.b=etPRHgNL; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: nvidia.com, ip: 40.107.243.76, mailfrom: jbobek@nvidia.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D+qg457iPBfUvUB6FMiWW6aqawSNm3unuLRbwCL1F5mPioPz0aV+bqKsfiT+nPcr3wbQcuc/80MpQEFCICV77VzlQFQHaTvDcv295k1U3fauy4NqntDjhBVEtqAqEJxhhNgFa4DgU7xODEzPAJMolvohpoe/yRki4xGgRIqW0K45PNu7CCGkUNtzJeAqm+PIPZgtVtOWU8oSy10Qn9xpeXlAOrzrBcFsDFQgNdYHgXOq9TL4q1QiyY641WZFqnjq5QlnCjphQIEbnLB/aOLXDQFuqD5Uz373hrsWI8xOsrBc19SQL8nDAMrDi+eOjbVTMcIbXnHKbMjJuHaOztix7w== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TaSZSui5LSRW0+a+xdl86cIKtYAYJGAcT1HAWW3533Y=; b=jp8vofmSIuUKfOY0FBzcwLZYZVnAnGmCcVn2PltylmgB+lAiG7d50QpKyQOBhJU8g65LPE8m93V8af3Gsy3AhnMCHvPrKtsJhdIvMzy6nmgJ1FQlf5G/UtuFGkaWNXEwG5DhXYgQJlr7vuMDggU7F7q0eZ25El8tMF62U85xUpq1SrgzSDYNrD3xYFKUlxhVE1j3oNu+i71v4HeyBOtuVOwG+NK7wTfBIWj8zZbu4mMU2lXKkqMiRFK4cqI0m+7LCd21ipWNo7QlBsksm1m+uokV02xqEodwqTjSeCvlIU6q8sYgBQTPqHK2hM5AvQS0OYlMpgIIv3dtlr/kIwTjgA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.117.161) smtp.rcpttodomain=outlook.com smtp.mailfrom=nvidia.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TaSZSui5LSRW0+a+xdl86cIKtYAYJGAcT1HAWW3533Y=; b=etPRHgNLkMWwZ5W4LAmZBmmcUtUSmSDolvNgUNopa/HEXEIeDTsl97ZsaZh8HdNGeYnmYAUEGWaR1o0g0NHhgD2DcbSA2hSOWeXG0nko/nT9J2/YiivdpAF4BmXIMW3bqajFCXed3cjigtlitCxUepBxLvK0VWn2lsQOGeBn5mWuLerhH9Ry4oBK17EmG9GdElChyXbzXDCwUoxtPCVi8AjtJi8+UQ7QrJiF1aaitz99sRLJ3DIRd0E7lqQNX5x/M0lZjlPKYuGWxWgNHmMptT2hDg4bgyu4VrG72tFRdGy10JmhBOiKxcjeIei8PQFFQ49ol51cFf7/atvlDYoTHg== Received: from DM6PR12CA0024.namprd12.prod.outlook.com (2603:10b6:5:1c0::37) by BL3PR12MB6596.namprd12.prod.outlook.com (2603:10b6:208:38f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.19; Wed, 25 Jan 2023 21:38:27 +0000 Received: from DM6NAM11FT104.eop-nam11.prod.protection.outlook.com (2603:10b6:5:1c0:cafe::6b) by DM6PR12CA0024.outlook.office365.com (2603:10b6:5:1c0::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.17 via Frontend Transport; Wed, 25 Jan 2023 21:38:26 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.117.161) smtp.mailfrom=nvidia.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.117.161 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.117.161; helo=mail.nvidia.com; pr=C Received: from mail.nvidia.com (216.228.117.161) by DM6NAM11FT104.mail.protection.outlook.com (10.13.173.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6023.16 via Frontend Transport; Wed, 25 Jan 2023 21:38:26 +0000 Received: from rnnvmail201.nvidia.com (10.129.68.8) by mail.nvidia.com (10.129.200.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.36; Wed, 25 Jan 2023 13:38:14 -0800 Received: from localhost (10.126.231.37) by rnnvmail201.nvidia.com (10.129.68.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.36; Wed, 25 Jan 2023 13:38:13 -0800 References: <20230120225835.42733-1-jbobek@nvidia.com> User-agent: mu4e 1.4.15; emacs 27.1 From: "Jan Bobek" To: Sean Brogan CC: "devel@edk2.groups.io" , "jiewen.yao@intel.com" , Sean Brogan , "Laszlo Ersek" Subject: Re: [edk2-devel] [PATCH v1 0/4] Don't require self-signed PK in setup mode In-Reply-To: Date: Wed, 25 Jan 2023 14:38:12 -0700 Message-ID: <87bkmmxpkr.fsf@nvidia.com> MIME-Version: 1.0 Return-Path: jbobek@nvidia.com X-Originating-IP: [10.126.231.37] X-ClientProxiedBy: rnnvmail203.nvidia.com (10.129.68.9) To rnnvmail201.nvidia.com (10.129.68.8) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM11FT104:EE_|BL3PR12MB6596:EE_ X-MS-Office365-Filtering-Correlation-Id: a36437a9-0608-4440-c360-08daff1c7e4b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: js6CoDCFw6AwF5hvTItNogJoxmJ/X+r4L6X/0oMLvEWWPbRlcQlQJ6ZQf55/vb9FdQsoCXKeICok80kdO/Xx9kDRHpcKtRjfmRRTeejxEqF/AUFA6drKhCRUsjLlA8/EOYz1O45N2MFVwTwnuof/lhe9AA31H3dO9pTpYQt36ybcaIr7bHYBA7fKiqncBViOW/rZ6dZbR1iBmDFsz+ggs/BCeO1aqBmIC9zafvH1q1UMsBevaxF1/X4JPQTK6bBhmKyXRkDJssiiULnmjwdBBuBolRFSawyosD7+DDB4+R/0Zk+B70wdgzvWM65Ei8+NSTEASEZtO/dcRGIxNV6VYXguiw0KAf1UjW2GctTjWfmQcvk/oJZL+YMpy5ZZFWUr9heFa/OLTFy+UMt77UWzktma+r5jXsxRQa8dL7z7xj/49RjflBNbX11FZX1lkRZSISuvrusMoL5Z3aDCU1J8GKWLvI7xEuYvAk7xbQn0oQCPqso8R8GTKZpNv1oBMrdbJx8qswaXcyi/4PY9T1GDtWO8UlSr3BdIcx2/ZCToVJNAGkPbKCzRtdljCM3hCWdmqfPf5S01+fQrAYuxqCqo66x73TbQneJvLqWUb6ifZe7vLzTUWNIcPCp3kGzXlPZGrslMDwqtq0wkZFd8x/+7FrirTSIi1u8iyDfo6DpnWZo1y+l+lM2LlHzcBUmud2K15QiFH9QW8UOmOzRYMzymwjx1LD4yD9hIbMR0HFMpZM9QsMGeJU9onnUc7fFfScX4wVgsMQ9ES18+zAE5Y0B1vtDUvy/IjYddKN40L9R1QA0dedXOY1gGtfkluKAVu6L7v366OM+3mt+FeppTF3yvgw== X-Forefront-Antispam-Report: CIP:216.228.117.161;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mail.nvidia.com;PTR:dc6edge2.nvidia.com;CAT:NONE;SFS:(13230025)(4636009)(136003)(396003)(346002)(39860400002)(376002)(451199018)(40470700004)(36840700001)(4326008)(8676002)(426003)(6916009)(316002)(478600001)(966005)(16526019)(5660300002)(7636003)(82740400003)(356005)(86362001)(40480700001)(40460700003)(54906003)(82310400005)(70586007)(36756003)(70206006)(8936002)(53546011)(186003)(83380400001)(2616005)(19627235002)(26005)(336012)(41300700001)(36860700001)(32650700002)(2906002)(66899018);DIR:OUT;SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2023 21:38:26.7845 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a36437a9-0608-4440-c360-08daff1c7e4b X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.117.161];Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT104.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6596 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Sean, > From looking over the patch 1/4 email i have a concern. > > In AuthService.c on the conditional change you made. Aren't we losing > a case where we are evaluating a nonPK payload signed by the PK? > Given the system is in SetupMode that means there is no PK but is this > the conditional path that is used when installing Secure boot keys in > reverse (DBX,DX,KEK,PK) order? Thanks for sharing your concern! They way I think about the change is that I've replaced the expression IsPk with FeaturePcdGet (PcdRequireSelfSignedPk) && IsPk and nothing else. When you look at it this way, it's fairly easy to break down how it affects the logic: 1. Assume PcdRequireSelfSignedPk is TRUE. In this case, the two expressions are exactly the same and no change in behavior occurs, just as we want. 2. Assume IsPk is FALSE. In this case, both expressions evaluate to FALSE, no matter what the PCD is configured to. That's also good, because we don't want to change how non-PK payloads are handled. 3. In fact, the only change in behavior that occurs is when PcdRequireSelfSignedPk is FALSE and IsPk is TRUE; here the former expression would be TRUE, whereas the latter is FALSE. That's exactly what we want: we wish to enter the first block of the if-else branch (which changes the variable similarly to when we're in custom mode) rather than falling through to the third block (which checks the self-signature). To directly answer your question, I don't think the behavior changes at all when processing non-PK payloads, by virtue of IsPk being FALSE and what I said in point (2.) above. Additionally, yes, the first block of the if-else branch is exactly the path that's taken when enrolling KEK/DB/DBX in Setup mode, and one that has always been available even without Custom mode. It used to be that you couldn't use this path to enroll PK without Custom mode (precisely because of !IsPk in the condition), but I'm hoping to enable this path with my patch. Let me know if I haven't answered or misunderstood your question. > Is there testing you have done? This code should be pretty easy to do > host based unit testing on. Any chance you have authored that to > confirm use cases are not unexpectedly impacted? Example of host > based unit test of library is here: > edk2/SecurityPkg/Library/SecureBootVariableLib/UnitTest at master =C2=B7 > tianocore/edk2 > (github.com) I've done an ad-hoc test by commenting out the switch to/from Custom mode in EnrollFromDefaultKeysApp from SecurityPkg, booting in Setup mode and using the modified app to enroll the keys. You could do a similar test from the OS, but in my case this was more straightforward. I am aware of the host-based unit testing library in edk2, and I agree that it would be great to have the code in AuthVariableLib tested for all the different cases. However, I don't have any such tests right now, and while I'm willing to potentially look into writing some, I'd have to do it more or less on the side, meaning it could take a while. Best, -Jan > On 1/22/2023 10:13 PM, Yao, Jiewen wrote: > > Hi Sean > I would like to hear your feedback, since it is a little different from t= he original MSFT patch. > > Would you please take a look? > > Thank you > Yao, Jiewen > > > > -----Original Message----- > From: Jan Bobek > Sent: Saturday, January 21, 2023 6:59 AM > To: devel@edk2.groups.io > Cc: Jan Bobek ; Laszlo Ersek= ; Yao, > Jiewen > Subject: [PATCH v1 0/4] Don't require self-signed PK in setup mode > > Hi all, > > I'm sending out v1 of my patch series that addresses a UEFI spec > non-compliance when enrolling PK in setup mode. Additional info can be > found in bugzilla [1]; the changes are split into 4 patches as > suggested by Laszlo Ersek in comment #4. > > I've based my work on the patch by Matthew Carlson; I've credited him > with co-authorship of the first patch even though in the end I decided > to do the implementation a bit differently. > > Comments & reviews welcome! > > Cheers, > -Jan > > References: > 1. https://bugzilla.tianocore.org/show_bug.cgi?id=3D2506 > > Jan Bobek (4): > SecurityPkg: limit verification of enrolled PK in setup mode > OvmfPkg: require self-signed PK when secure boot is enabled > ArmVirtPkg: require self-signed PK when secure boot is enabled > SecurityPkg: don't require PK to be self-signed by default > > SecurityPkg/SecurityPkg.dec | 7 +++++++ > ArmVirtPkg/ArmVirtCloudHv.dsc | 4 ++++ > ArmVirtPkg/ArmVirtQemu.dsc | 4 ++++ > ArmVirtPkg/ArmVirtQemuKernel.dsc | 4 ++++ > OvmfPkg/Bhyve/BhyveX64.dsc | 3 +++ > OvmfPkg/CloudHv/CloudHvX64.dsc | 3 +++ > OvmfPkg/IntelTdx/IntelTdxX64.dsc | 3 +++ > OvmfPkg/Microvm/MicrovmX64.dsc | 3 +++ > OvmfPkg/OvmfPkgIa32.dsc | 3 +++ > OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++ > OvmfPkg/OvmfPkgX64.dsc | 3 +++ > SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf | 3 +++ > SecurityPkg/Library/AuthVariableLib/AuthService.c | 9 +++++++-- > 13 files changed, 50 insertions(+), 2 deletions(-)