From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mx.groups.io with SMTP id smtpd.web11.23750.1671461248014610525 for ; Mon, 19 Dec 2022 06:47:28 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="unable to parse pub key" header.i=@intel.com header.s=intel header.b=Ll7EDDq4; spf=pass (domain: intel.com, ip: 192.55.52.136, mailfrom: jiewen.yao@intel.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1671461248; x=1702997248; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CLlwi9lAOrT+3vVxkMvtZCpFWzsYRo1XSirzUsQpIw0=; b=Ll7EDDq4Srh6tYkSLjmq+X3A5CLWTQl3iYBIKERxGY/tla87ltL6EObw N25KATTLtgPuyUbBJG1d9ZHl3OXK0lDgwV6aOzFjHsDVOHkDzz6J3G2l9 xi1K73iLhztxnLIDZJbM1MBCZNqh8rb9vRmHftZxr8Vbb235OQM6nS4Z8 UNAS7Vt9k4wwQXBYjXXc+GdLkIjdL/YRsQSAM7A+4uyGz+hpQPRn5xpB7 rVf5QBvp/rlOimcQVpvAukIAreQRdWA0cBOb6GUwdFswKB8QNvhkLhhsI yijRccZ21w7ru6fQLef3gk4n7gONpfUuujhO3qX+nX3enTuT1hf3hmq52 w==; X-IronPort-AV: E=McAfee;i="6500,9779,10566"; a="299040189" X-IronPort-AV: E=Sophos;i="5.96,255,1665471600"; d="scan'208";a="299040189" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Dec 2022 06:47:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10566"; a="757643755" X-IronPort-AV: E=Sophos;i="5.96,255,1665471600"; d="scan'208";a="757643755" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmsmga002.fm.intel.com with ESMTP; 19 Dec 2022 06:47:27 -0800 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Mon, 19 Dec 2022 06:47:26 -0800 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Mon, 19 Dec 2022 06:47:26 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Mon, 19 Dec 2022 06:47:26 -0800 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.103) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Mon, 19 Dec 2022 06:47:26 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ni5tXV3NvHdLIvfWLxIibuRT5BWGG7YKXdUBB71nDlLqPBB5pvtnGLUs/YSUh/2kLazfAEfhLd/JMHCDDY+IAIUVWR96HaeoUqo2Oo+ulfL2IsWN+6F3rZa+VLZLFV42WLtDscNdC9845JaBbZEO7F3rQyQhiRtV8r4IPWdmRMExYCrwufysktDFqUh24SpDjwF7GD0AEf8Gdu/yjyPXDZCVBVKeNjxgfo+yB1xsOFBO7h5Xeq8/UwR09Hve0sbU4Zc8eAkFCdP0nLGx2yEE5wy3a92BM99o4xoFqOFQ8hsr77K+RAnaca7Wxuw1j7reXD4mEB8NIPtliIWmTf7XTQ== 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=qUq0rdoetWlWOgp9KYv3XCDm53sozpOwu19QPVWMEKo=; b=GUNrxHPOfsGbYooTrURO+kmix11l/KinayiVr/Pjm3PvoTkfRWuRTx0+kqk347ys7FpHpaz6/judf5DoFyFh0XYiRbweLimtVcNQnjHSZj4On05R1xpCBI3NIghSz7woCpsd15KHuUUd8EK0+pbhuu0Ye2s3gERWHePMyFgRBTA+8A0ZbTqmcvsZttuMADhUiDgcMK91FXymCX+/0aZYU0umh+lmHUEgYYtKyhXOTxBYKV77H4JEkhbcvj7umTueJj7O1Z08Aco1b/TpHM7i9SyOLFyj4IfkYCAKT7bFHYgpU0+Ow6tTo/990rLYknvogwT0GChdsgNvo2O1ZLdmJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from MW4PR11MB5872.namprd11.prod.outlook.com (2603:10b6:303:169::14) by CO1PR11MB4996.namprd11.prod.outlook.com (2603:10b6:303:90::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5924.16; Mon, 19 Dec 2022 14:47:24 +0000 Received: from MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::5f56:1bdc:2eae:c041]) by MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::5f56:1bdc:2eae:c041%8]) with mapi id 15.20.5924.016; Mon, 19 Dec 2022 14:47:24 +0000 From: "Yao, Jiewen" To: "devel@edk2.groups.io" , "kraxel@redhat.com" CC: "Justen, Jordan L" , Ard Biesheuvel , Oliver Steffen , "Pawel Polawski" Subject: Re: [edk2-devel] [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning Thread-Topic: [edk2-devel] [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning Thread-Index: AQHZETbWM5zr0lwsBkqfXhaXhHkp1K5xYs9QgAOJXoCAAFfEIA== Date: Mon, 19 Dec 2022 14:47:24 +0000 Message-ID: References: <20221216101134.2201546-1-kraxel@redhat.com> <20221219085303.gzqitjjjex3mauve@sirius.home.kraxel.org> In-Reply-To: <20221219085303.gzqitjjjex3mauve@sirius.home.kraxel.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MW4PR11MB5872:EE_|CO1PR11MB4996:EE_ x-ms-office365-filtering-correlation-id: 50d8a993-ecd1-401c-fcdb-08dae1cff134 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WVS5jc1170LBsDaSdhOO9ynInUaAwtABW9srOVSkjWuHTImbiMorRDQ3gxABD5HluCSKcrXk+lXen10uqQE+ECQE2J7s38w4vUhBW0x3Hw//FxxFdUgoCbcjNM6tdLuveNFrTwPthaf9ojTbKGgqrp08UwvNOSrWYEDDXPa7froffMd5/jtZRpytBNJKHHqfDBsF6muAzTG9uMM76FaoNpLYy7RjmWt5ck2WDYo/vSE9oyuOYBBfYXlQwLx8PjaipRfm5a+/x7ShwyW0lYgKcsdykar2t6eIOkSwnEkphQu8qwx72hcd0djbu+Wjpk7Gn7/JVCE3kvnHETmJcuVrnbFOa6fBsynT7fGMIloXKbWhZq8in7WQ5bXCcfyw+csatfXa1uIm7g537QGwkEGz48jA90X817hHSnqaRMfFeGandfqOh78y1TLT9p95qXNPmHmlsIGy4d/O9YC9CJ4GcwsIAv2ZEfUFNnfRdq/Oj5DtAwDKkfAke/YUU/Q3s18vcoc9LpkUwD7uBkWJrYzjxsFmfGvWJoAyM10E0DNyj6F3qda6jcU6m8yNw5+aBih/MKKhZQG+oqDD2UobzVeUEJR+bnCMRZPw6aQ0BeWuBe2z3kFwgKLI2VF2GNrzaTg0+YEKLSUCM9ZjMhQ4ZDy7TyR23n5EbjBGfLO84lvTnEqAkmYYM1DMricNiTXJff/SI28E5MajmoE5Vc3X7ZL+nPBY1cnjszZozA2KF93zohPCjQpaWBl/GMvMl0F44OH+4ale0tS1GTj+PVueFWvt9dCRr0f2jABbcCOTQ5wqetU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4PR11MB5872.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(376002)(346002)(366004)(396003)(39860400002)(136003)(451199015)(33656002)(8936002)(83380400001)(5660300002)(52536014)(66899015)(26005)(55016003)(15650500001)(41300700001)(186003)(2906002)(9686003)(966005)(110136005)(71200400001)(66946007)(76116006)(478600001)(82960400001)(53546011)(66476007)(4326008)(316002)(8676002)(64756008)(38100700002)(66446008)(7696005)(66556008)(6506007)(86362001)(54906003)(38070700005)(122000001)(213903007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?qEiqZdzdGJPz4nd/I8b/sjuWP009DParwvuEgvCrheQ2/89ytXZtZ7Xq/wjm?= =?us-ascii?Q?ZVtfloRPU3DAW6J92i7hMO5ur5DuyUvI0kZoRcbNjMLtWUoi0RseMr6yEo4y?= =?us-ascii?Q?sQCpo8Vqc9duQ4233W5sMQt4pfgujcyLQ5tWZ/rhPt0bqmJ3OgFVjbuyl8FX?= =?us-ascii?Q?LDln1Eg2jjp/8MjgttS7G26C2pR+iVhrYFfav7isY0C6LRgKR98cQgcBq85J?= =?us-ascii?Q?qbSCKtS8yoaNcjJtBw6tlbnT42GNYdAbzoAfoX3s3tYbD7LI4vihYNkiCe3P?= =?us-ascii?Q?ACGUY16f1tEsQAMM89jWnWF1QpUgvIdMDENbM+ID2U432u53TmWAwV64llcv?= =?us-ascii?Q?rnnXMS/A6ty51O+HUUJt4CA7/AU76Qr12DqmNFgczseoRfja7RsQCCzwxLbI?= =?us-ascii?Q?HNAtblnhEf5HG3SZ2nTnIZgmmY0IobGxywYPx/NEVK3NisXWncWmAzkCoW7H?= =?us-ascii?Q?omHeqvTrrUjXraUYJU8OPCU3nbQA93FSwu5n9jUOfEiEjquoeTcQhb1vvVcU?= =?us-ascii?Q?iOFuFo9lZxTQBJ46y1hF/WwS3yVKGq+jaqDn84blr9wTZphIF1dxX3S/EiKd?= =?us-ascii?Q?eXB5GEBBjNBTTCKfLkNY+QHhK6EvTklquxmKUCIP5mA0S8DtMwbTdiw2X4Hb?= =?us-ascii?Q?y35ZQ6eVMIjAKMShhR/IeNdOCMBgtb8NHdNAOr6anZpOHznPuNJMoEtoH9l4?= =?us-ascii?Q?vyTxLRcIuA0xCRCZpeY8La04+bdnli/lZT46QulQn3bsFYdYTASN7rdV2htw?= =?us-ascii?Q?I2OR1XkRMbDlBKH1NaJuTDA9mbq8HiIgBjae5U4OwyQH0jgUo8V1hREqKPDD?= =?us-ascii?Q?VVEawiZyY919lYFStrH6/mWEEJV/r2X4Bw9croJnkUGtCRFDhK2mVpmqgOOq?= =?us-ascii?Q?GEUeS50HHG69PV+l9uFQ0h1ePKkyPQSw2Xf/ZzXbViBi9aLJ0UnszhoPsDOG?= =?us-ascii?Q?YirQ/BujssiBO9OdmAQ4idAhPArbC5fJcDRzJz4XMQMxxqyKtablm0JEgqab?= =?us-ascii?Q?CSJG46LygqFvBnu2db8uWYOEhkqkjg1sXzk+mMqsKHKeLTgS8ONc4qJ0I0Vs?= =?us-ascii?Q?ko0yCeCwxE4IEACTCAt0RGBEF1Bp6bSUXnkJK+c4szzmzj5qEXFwkMnBBc5L?= =?us-ascii?Q?HinK8qjD+ZX1x9rifOEa5CroypAOiRrmZzWDEgmwdFzkZNnTd60kCdkm48i5?= =?us-ascii?Q?tEMkY6k2gJ/SRDGDKxLxAgjFQMdW2HkLrWV5tzcBEwplfE0vMnWfkG9a1ix7?= =?us-ascii?Q?34vLsa302hB/Xc5k9OtzX4eGW86fjc209P0hm4ZBYBOL/yaLwL9Tf1G2XcQI?= =?us-ascii?Q?NoTlaVylu2lYu7ytj1VskvDNs2oPyMrdmvkEQslLsiy3q3tu9yyDSIhzGy0w?= =?us-ascii?Q?dbcMO1VRpssIdiuiJ4yax9q7gqz6Y29371tBeXOoI27KKEbiAwhxNnI/ETtd?= =?us-ascii?Q?X3pTZReZLjUaakmamG5zvYVPPA9PN8V3eGFbckVDRog363iVXfRf/feFc7h+?= =?us-ascii?Q?WeR5mlcZXYB8JXuTPXkud8wpJeW56/2agITkZe9A2LPXbNNbPiMaO+vFghNd?= =?us-ascii?Q?NIbLzSGa/zGL9YqRqpvpTSlBUEZYod7UH0PPZZdk?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4PR11MB5872.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 50d8a993-ecd1-401c-fcdb-08dae1cff134 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2022 14:47:24.7139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: otYwtYSlPT0fNsZD5kY6XJLigt/hl4ocy+FI0tnX7GfwoDN+WcKCQACs5R91D7KoHoYiHdLTwnNNQB8zk93hTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4996 Return-Path: jiewen.yao@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Gerd > Hoffmann > Sent: Monday, December 19, 2022 4:53 PM > To: Yao, Jiewen > Cc: devel@edk2.groups.io; Justen, Jordan L ; A= rd > Biesheuvel ; Oliver Steffen > ; Pawel Polawski > Subject: Re: [edk2-devel] [PATCH 1/1] > OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning >=20 > On Sat, Dec 17, 2022 at 03:10:25AM +0000, Yao, Jiewen wrote: > > Hi Gerd > > I would like to clarify a couple of things: > > > > 1) "Using these builds with writable flash is not secure." > > > > Whenever we say "secure" or "not secure", we need align the threat mode= l > at first. > > What component is trusted? Which is not trusted? Who is adversary? With > which capability? Under which attack scenario? >=20 > Well, the OS can write directly to flash, bypassing the firmware. It > can update secure boot efi variables without the firmware enforcing the > usual restrictions (KEK signature being required for db/dbx updates > etc). [Jiewen] I would say: It is the typical use case. But not the only use case= . Typically, the BIOS shall configure the flash to prevent OS directly to fla= sh, with SMM in this case. I do not disagree. That feature fully really on the hardware (on a real platform) or VMM (on a= virtual platform). However, in confidential computing use case, the flash is controlled by the= untrusted entity - VMM. It is *impossible* to lock down the flash, even with SMM enabled. That is b= ecause the VMM is also emulating SMM. To rely on an untrusted entity (VMM) to provide security protection (e.g. S= MM) is meaningless. The best way we can do is to enable measured boot together with secure boot= . As such, no matter how VMM or untrusted OS modifies the SecureBoot variable= , it will be recorded by measured boot mechanism and detected in attestatio= n later. In summary, Secure boot in CC cannot resist the policy override, but Measur= ed boot in CC will detect such override, and mitigate such threat. That is fine, because it is meaningless to enable CC without measured boot. >=20 > > If we are going to say something like that, we need a full description.= Just > saying: "not secure" is not enough. >=20 > We simply don't get the protection secure boot is supposed to provide. >=20 > > 3) What is definition of "stateless secure boot configuration" ? > > What does you mean "stateless"? Do you mean "SMM_REQUIRE=3DFALSE" or > something else? >=20 > "stateless" means we don't have persistent efi variables. >=20 > > Then why not call it as simple as "secure boot without SMM" ? > > I don't understand how "SMM_REQUIRE=3DFALSE" will contribute "stateless= ". >=20 > Secure boot in OVMF in 2022-08 + older requires flash memory as efi > variables storage and SMM mode support to enforce all efi variable > updates being handled by the firmware. >=20 > Starting with 2022-11 it is also possible to use secure boot without SNN > mode and with the emulated variable store in RAM. Min added that for > IntelTdx. The firmware can't enforce variable update rules in that > case, but that is compensated by initializing the emulated variable > store content with a pristine copy from ROM on each boot. So the OS can > tamper with the efi variables, but it can't attack the system that way > because any changes done are wiped on reset, before the firmware looks > at those variables again when checking efi binary signatures. This also > means any regular efi variable updates (like setting Boot* variables on > install) are wiped on reset too. This is where the term "stateless" > comes from. >=20 > I don't see how "secure boot without SMM" is easier to understand than > "stateless". [Jiewen] "stateless" is a new term introduced in this patch. Not in UEFI sp= ec, nor in EDKII. If you want to use it, please define it clearly. At least, I don't understa= nd. > It also is x64-specific. [Jiewen] I don't understand why it is x64-specific. > But the idea to give up variable > persistence to get secure boot support without processor support for a > separate privilege level can work on other platforms too. ArmVirt for > example could get secure boot support that way without depending on > TrustZone. >=20 > > 4) What is the purpose of "Log a warning" ? > > Is that to tell people, DON'T DO IT? >=20 > Yes. [Jiewen] Disagree. It can work together with measured boot in CC use case. If you really really want to add something, you should also check if CC is = enabled. >=20 > Maybe it's better to refuse to boot in that case,=20 [Jiewen] You may refuse in non-CC case. But it is legal in CC case. > a warning in > a logfile is easily missed. [Jiewen] Yes, that is why I don't like WARNING in log. I think we had better describe it in readme. >=20 > In 2022-08 and older the world is relatively simple. We have > three possible build configurations >=20 > (1) SECURE_BOOT_ENABLE=3DFALSE SMM_REQUIRE=3DFALSE > Build without secure boot support. >=20 > (2) SECURE_BOOT_ENABLE=3DTRUE SMM_REQUIRE=3DTRUE > Build with secure boot support, secure. >=20 > (3) SECURE_BOOT_ENABLE=3DTRUE SMM_REQUIRE=3DFALSE > Build with secure boot support, not secure. >=20 > Linux Distributions typically provide builds for (1) and (2), > so (3) existing isn't much of a problem in practice because > people typically don't compile edk2 by themself. [Jiewen] Above description is based upon assumption that SMM is trusted. It= is TRUE in non-CC use case. However, the assumption is wrong in CC use case, because VMM is untrusted a= nd SMM might colluder. The VMM may fake the flash lock in SMM, and allow OS to bypass the flash pr= otection. Following your logic, I would say: even with SMM, it is still not secure. The only way to make it secure is to add measurement and attestation in CC = scenario. >=20 > In 2022-11 the (3) case is splitted into two: >=20 > (3a) build being used with ROM (or r/o flash): > -> this is the new "stateless secure boot" mode. > (3b) build being used with writable flash: > -> insecure configuration. [Jiewen] If you want to use term "stateless", please define it. Also, I think we can separate the non-CC and CC use case, because the TCB i= s totally different. >=20 > Now the same build can be secure or not depending on > runtime configuration. So this patch tries to catch > (3b) with a runtime check. >=20 > take care, > Gerd >=20 >=20 >=20 >=20 >=20