From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@virtuozzo.com header.s=selector1 header.b=WZlC+UdY; spf=pass (domain: virtuozzo.com, ip: 52.101.134.108, mailfrom: rkagan@virtuozzo.com) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (EUR03-AM5-obe.outbound.protection.outlook.com [52.101.134.108]) by groups.io with SMTP; Thu, 01 Aug 2019 12:16:35 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DHMVYPSAUMdzBAzWH/Fkkd5g+GgZ9+NKqdNLavQ0ycF9VDhnqRNqNjNaHicRAg0jljqkJdWbOAYU5p1v02z5efu7fI5k5mxH9eXyCEpQp0s5C0s7PutiKwsWUJdxKBe51NqR92A0/CY7+8HGnlcEYiGJj/hNfhTnRMbk0Bl9cxdwe2gEIc9OTdY/t87A87wor3B2Rgr8JoAP5zkKdf+zlxtT++BFJ7+To+P5aSGrjXls7wzkMQRxXv15OyIJ3qtTc57gQbtv+GmdXQtYxL8MT2EfVJBLOsuGerTKmn8hv5hoMdIAOfBJMaBqoO1Zk6gvim/zzqKJCfB0XLtqWkaNjQ== 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=+4MGEQMZZa1OXxJ3s26PmerOqjl0FFIdTid1UBM/xKs=; b=eIaeOR/Tc5ZMPUjR2qn+tlkLxC/stmoCQdZMJfIeWq08W9TT0+mHpXEs5v7GiS1i3q9u4DcoRtzvdp/m3FIYWa2o9LL31EgScK9BfMrabofPlHrV4mNk2t+BWa+JHr4rOYwH3GjY6d6oFi9b01JbLxmBF+L21a3itmhYHOVr/2/ufXyqQnsQbXiQwQRY8NO/w6I/JmKjbS11OlD1FJb4cGaJpkOSoF8r2dfUQOTg451lx/ORgn2vGzKd4resTRiqzNNw9naHOthew6LIZc6uSLaPwvKAjnbI6SAhXKTG7ekVphVrKaCaKNcARd3qvp1KpmocfJhhBovgUM8kuf6lYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=virtuozzo.com;dmarc=pass action=none header.from=virtuozzo.com;dkim=pass header.d=virtuozzo.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+4MGEQMZZa1OXxJ3s26PmerOqjl0FFIdTid1UBM/xKs=; b=WZlC+UdYgBxqysJ2bmgkOhh5vTaqecFCimrkngV+SPqXz+oG/aherEIa/1BxtaVpph91jH2C+1ZwMoaQErTICBlVKMy4Z1V3sUvOlNs41gJPYreKTToARbnJ01Qcdr1XYQCCbrFizW+p/0sGqTqf4Yb53Pl0Rkn1aPFMkIXK7yk= Received: from AM6PR08MB3160.eurprd08.prod.outlook.com (52.135.163.161) by AM6PR08MB3736.eurprd08.prod.outlook.com (20.178.89.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.12; Thu, 1 Aug 2019 19:16:24 +0000 Received: from AM6PR08MB3160.eurprd08.prod.outlook.com ([fe80::2c2c:c46e:bdfd:b872]) by AM6PR08MB3160.eurprd08.prod.outlook.com ([fe80::2c2c:c46e:bdfd:b872%6]) with mapi id 15.20.2136.010; Thu, 1 Aug 2019 19:16:24 +0000 From: "Roman Kagan" To: "devel@edk2.groups.io" Subject: static data in dxe_runtime modules Thread-Topic: static data in dxe_runtime modules Thread-Index: AQHVSJ2bQrdLTZ7e0UaPDsZ6ZQsRbw== Date: Thu, 1 Aug 2019 19:16:24 +0000 Message-ID: <20190801191621.GB14235@rkaganb.sw.ru> Accept-Language: en-US, ru-RU X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mutt/1.12.0 (2019-05-25) mail-followup-to: Roman Kagan , devel@edk2.groups.io x-originating-ip: [185.231.240.5] x-clientproxiedby: HE1PR0901CA0055.eurprd09.prod.outlook.com (2603:10a6:3:45::23) To AM6PR08MB3160.eurprd08.prod.outlook.com (2603:10a6:209:45::33) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rkagan@virtuozzo.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6da5520e-ecc9-4270-3ac6-08d716b4be63 x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);SRVR:AM6PR08MB3736; x-ms-traffictypediagnostic: AM6PR08MB3736:|AM6PR08MB3736: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01165471DB x-forefront-antispam-report: SFV:SPM;SFS:(10019020)(39850400004)(346002)(396003)(376002)(136003)(366004)(199004)(189003)(102836004)(478600001)(7736002)(305945005)(58126008)(316002)(33656002)(6436002)(6916009)(6512007)(476003)(256004)(14444005)(5640700003)(486006)(5660300002)(8936002)(14454004)(81156014)(81166006)(1730700003)(8676002)(9686003)(66946007)(53936002)(66476007)(66446008)(64756008)(66556008)(68736007)(186003)(2351001)(66066001)(36756003)(1076003)(2906002)(71200400001)(52116002)(6486002)(6506007)(26005)(386003)(2501003)(86362001)(6116002)(3846002)(25786009)(71190400001)(99286004)(30126002);DIR:OUT;SFP:1501;SCL:5;SRVR:AM6PR08MB3736;H:AM6PR08MB3160.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: virtuozzo.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: twLS5S6z6ZSmJYMsPLvlhQVEbxiRj2BpLvMGJnMjplEc1tljsxw31PDCWWWxweXCcdozqn7adG1FsHTuH174oo1op/nbCJCah/80R42Ait1ClBRitVusCXDbw3tO2cSSssJz6cGZZ7Rsml5xfzjkUQk0ysejx5SslTo/FHYgHgITFwTpAiWkM9pafRC/ncLkewlP0qY/JtqGwBih56iRCCuxlbV2MilubWZZzXbNfNJWYDQ4Z2nXhKDVDpFYVAJf4p1FjbljLOMkJCfXyuSm3WybZ41DR3jTZbbj3a9c4FJdM71b7fT7DZa9WU3ruz7STT4hmyKktDDCvIcar7dmcJyARuZWwByXLHJSpxsVMl1QWjhRATNB1+KPzH3wmu5/qmubWUPTUkZ0C2OfKvx1bwdRG2ZUYMN4nqxt4RVNSecyNFvuA7kWk2fl6ud3EMOCft2guLGUARs4sNZwmX6UGYA17aMkAbTag87Kobd9k+TySGCar5Z9FrMk0oevyy18 MIME-Version: 1.0 X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6da5520e-ecc9-4270-3ac6-08d716b4be63 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2019 19:16:24.1552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rkagan@virtuozzo.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3736 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: I'm trying to come up with a solution to the problem that OpenSSL internally uses static variables ("per-thread" in no-threads config) to store pointers, which remain unadjusted upon SetVirtualAddressMap and cause the guest OS crash. More specifically, trying to set a signed variable leads to the following call chain: VariableServiceSetVariable ProcessVarWithPk VerifyTimeBasedPayloadAndUpdate Pkcs7GetSigners ASN1_item_d2i asn1_item_embed_d2i asn1_template_ex_d2i asn1_template_noexp_d2i asn1_item_embed_d2i asn1_template_ex_d2i asn1_template_noexp_d2i asn1_item_embed_d2i asn1_template_ex_d2i asn1_template_noexp_d2i asn1_item_embed_d2i pubkey_cb ERR_set_mark ERR_get_state The latter performs one-time initialization if needed, and then returns a pointer maintained in a static array using CRYPTO_THREAD_get_local(). If a signed variable is set before SetVirtualAddressMap and (another one) after it, the pointer is initialized while in the old mapping and dereferenced while in the new one, crashing the OS. The real-world reproducer: install Windows Server 2016 in a VM with OVMF, shut it down, replace the varstore with a fresh template copy, boot Windows, try to update, say, "dbx" from within Windows => BSOD. The reason is that the Windows bootloader stores a secure variable "CurrentPolicy" if it isn't there, triggering the above callchain while still in identity mapping. (This problem isn't widely noticed because during the installation the bootloader stores CurrentPolicy, but the OS is soon rebooted, before it attempts to update dbx; upon that CurrentPolicy remains in the varstore and on further boots the bootloader skips setting it.) What would be the best way to fix it? One option is to audit OpenSSL and make sure it either doesn't put pointers into static storage or properly cleans them up (and call the cleanup function in RuntimeCryptLibAddressChangeEvent); then assume the rest of EDKII code is safe in this regard. Another is to assume that no static data in dxe_runtime modules should survive SetVirtualAddressMap, and thus make PeCoffLoaderRelocateImageForRuntime reinitialize the modules from scratch instead of re-applying the relocations only. I must admit I don't yet quite understand the full consequences of either option. Perhaps there are better ones. Any suggestion is appreciated. Thanks, Roman.