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=W9xSBahW; spf=pass (domain: virtuozzo.com, ip: 52.101.133.47, mailfrom: rkagan@virtuozzo.com) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (EUR02-VE1-obe.outbound.protection.outlook.com [52.101.133.47]) by groups.io with SMTP; Mon, 05 Aug 2019 03:18:26 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bkrxqSNO5QRd4VAIzsrCn/CiRqKVm3dnVNU8Bfj+GlcEPv32TksPWpgUz+Y94pK2frWfdD49dt0kZsWkjyL3OwQwlJXSzX9FEbghMAewQREoYvWzmAVKPVCqIE0L9PtDOSK9nX0Mj/DWkh6R4bDNGWSKIjNWUvhXb03zH0N0l/gTukF5+Fe6kDMB0+HgdFac2D9K/A6o93qz1mylyJaBANjuSzRAt3s4QOCg+s6yJKBeY/W7VWr1mzY+5X93dbcQp4iYvMNYsshnX5CzQQBk0Uv8UuVSd9qLvv9CUDr9Bl/tXtJCKeU5VTF3JkBlU5oFhpPTf+izHo+Y5ApwrQD4Sg== 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=1i/NewuDPI1Lbot4jR9trE8XJfKPtD/RHE4NBQ5B1rg=; b=i2QenBlnhbg3zQUul6XYvTs82QUdqMn+jyGzc0WzfJ1AJEiiVF2yWfnKQPkevayDj5VPZ2xkLzj2kF3ZeMiiWHOgU/08PTwcWwKZPw0msuvmfl/cbHIaKLKJ1c4mAipdmfNVn8iV22s1/CXAgK3qD6AqJ2Vla2KKaYi8Ry0f8XSfskhSbi/GwqpxZd6rN7EwO9nnh0s7uT9l5reELzeKLX5pTDZOeAH2JyFzn5EnBHfQ1eX/9aMuKHIITztSxWlNcDoz6CacbO/TWe79GDgYvNkNhitS0dm1UpwsixXFXPKpxqIuyqbCVEgxCr9mj9sv/vOi1GS74J1Vfp4vIixJlg== 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=1i/NewuDPI1Lbot4jR9trE8XJfKPtD/RHE4NBQ5B1rg=; b=W9xSBahWWnFf3NxW2ERd86jtRrr87H06v32stpbHRYw+cE98vKA+QR7rdfKBU3xCBPeoZXKNYKltYZ4MNQgB5NW4Y51CW3dGz0Zj7RkOjN6/VUpNqmKkMO6n7JRZiu6K8ddk6Tum4tPxrWTmq82pTFanXGrkAy3CdxVXT9VqB/Q= Received: from AM6PR08MB3160.eurprd08.prod.outlook.com (52.135.163.161) by AM6PR08MB3527.eurprd08.prod.outlook.com (20.177.112.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.16; Mon, 5 Aug 2019 10:18:15 +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.018; Mon, 5 Aug 2019 10:18:15 +0000 From: "Roman Kagan" To: Laszlo Ersek via Groups.Io CC: "devel@edk2.groups.io" Subject: Re: [edk2-devel] static data in dxe_runtime modules Thread-Topic: [edk2-devel] static data in dxe_runtime modules Thread-Index: AQHVSJ2bQrdLTZ7e0UaPDsZ6ZQsRb6borfAAgAOvAoA= Date: Mon, 5 Aug 2019 10:18:15 +0000 Message-ID: <20190805101813.GA27171@rkaganb.sw.ru> References: <20190801191621.GB14235@rkaganb.sw.ru> <8d18d4f6-5f33-44e9-2758-46350b43c5ec@redhat.com> In-Reply-To: <8d18d4f6-5f33-44e9-2758-46350b43c5ec@redhat.com> 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 , "Laszlo Ersek via Groups.Io" , devel@edk2.groups.io x-originating-ip: [185.231.240.5] x-clientproxiedby: HE1PR05CA0271.eurprd05.prod.outlook.com (2603:10a6:3:fc::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: 35875772-f794-4cff-90d2-08d7198e3a8e x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);SRVR:AM6PR08MB3527; x-ms-traffictypediagnostic: AM6PR08MB3527:|AM6PR08MB3527: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:SPM;SFS:(10019020)(366004)(376002)(136003)(346002)(396003)(39840400004)(199004)(189003)(11346002)(6486002)(3846002)(6116002)(36756003)(229853002)(86362001)(446003)(256004)(6306002)(8676002)(68736007)(478600001)(1076003)(186003)(9686003)(6246003)(476003)(6512007)(81156014)(52116002)(6436002)(66946007)(99286004)(14454004)(7736002)(8936002)(81166006)(76176011)(316002)(71190400001)(71200400001)(58126008)(33656002)(53936002)(486006)(66066001)(26005)(66476007)(66556008)(2906002)(305945005)(5660300002)(966005)(386003)(6506007)(53546011)(102836004)(64756008)(66446008)(4326008)(14444005)(25786009)(30126002);DIR:OUT;SFP:1501;SCL:5;SRVR:AM6PR08MB3527;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: aV+vl81Qm3uttXxfb400CtYUvjBQ2kRAkZeKEHhZ1jJgMuJV82ry32TIOn6fHsAW6B7zIkoRycBtxuGz0pYqFc6Nj0Z8IPO/f2veapugh9tP7wUNwuwP9vzONONq4/2zKOr7AiOaxpbgtUny7tr1sljGy/W5CuQPapvi/h/aKgwntzmkBxHK9vo5LQAuQ7Mi6U93JcarJjPk8n2/QhgB2IgmH1wUji3bIZIfFU1VTOT8wj231EnmmgOpMhKfiCJHCax9LMJPHg0lLsJ+uctzuxIQPyloksHNRkOgrzTpWrBOLmfoM/jtrNfRjGv7wWD064KoFcDRvIif45+qI9qAoCQkcxWM0NUN4QhNDZOw4UksVzg15S/w0G/EuJerAmAB/4Tnh2vJC6dhsbKEKWyM6QKaBOdEQOgqvq2oi7G/lI2X0jvtBdUpZF+YhCbPqyXDck+rTnaOS7XneVcOQPvd5cPXi8CyNLdE9lAVO6GcOAD8G9CdhE7yLvjgYNAnG7e7 MIME-Version: 1.0 X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35875772-f794-4cff-90d2-08d7198e3a8e X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 10:18:15.6645 (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: AM6PR08MB3527 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: <0B30A09938D6284883840BA1F18D8BF2@eurprd08.prod.outlook.com> On Sat, Aug 03, 2019 at 04:03:04AM +0200, Laszlo Ersek via Groups.Io wrote: > On 08/01/19 21:16, Roman Kagan wrote: > This is a serious bug. Thank you for reporting and analyzing it. Can you > file it in the TianoCore Bugzilla too, please? https://bugzilla.tianocore.org/show_bug.cgi?id=2053 > I wonder how far in OpenSSL history this issue goes back. Is this a > regression from the latest OpenSSL rebase in edk2? This is certainly not a recent regression. We've initially caught it with Virtuozzo OVMF based on the one from RHEL-7.6, based in turn on EDKII as of May 2018. However, the infrastructure that causes the problem is there for much longer. > > 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. > > If the runtime driver remembers pointer *values* from before > SetVirtualAddressMap() -- i.e. it saves pointer values into some > storage, for de-referencing at OS runtime --, those stored values have > to be converted in the virtual address change event notification function. [...] > The "thread_local_storage" array from > "CryptoPkg/Library/OpensslLib/openssl/crypto/threads_none.c" has to be > exposed to RuntimeCryptLibAddressChangeEvent() somehow. > > Perhaps OpenSSL should allow edk2 to bring its own CRYPTO_THREAD_* APIs. I think this would be too awkward, as edk2 has no reason to have any visibility into it. I'd rather make use of the observation that in reality there's no data in OpenSSL that needs to survive SetVirtualAddressMap(). At first I started to cook up a fix that involved calling OPENSSL_cleanup() from RuntimeCryptLibAddressChangeEvent(), but it soon turned out it didn't clean things up to the pristine state so it didn't address the problem. Moreover I think it's overoptimistic to expect from OpenSSL developers the mindset that their code should work seamlessly across relocations at runtime. I don't see what would stop them from introducing another pointer variable with global storage further down the road, and nothing would allow to even timely spot this new problem. That's why I think the most reliable solution would be to just reload the module completely. If this can't be done for all runtime modules then I'd do it for the one(s) linking to OpenSSL. Roman.