From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (NAM02-BN1-obe.outbound.protection.outlook.com [40.107.212.57]) by mx.groups.io with SMTP id smtpd.web08.3485.1645912097274229815 for ; Sat, 26 Feb 2022 13:48:17 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@nvidia.com header.s=selector2 header.b=iMD+1lD3; 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.212.57, mailfrom: ashishsingha@nvidia.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PNBzEoO5aVS44zuWucDvpDLHv+G9ruZaZzJM5UTUq7ds7kGmaMiMScSD2BmtUCSJmHem7EQ8fLqUdXmtuemd4oSw7WZGwKSyeYq+Pn7TMXhWzMnGnJOLQbMBlAsnKatyP849pmFM5h18x5SfnTg0EGJ6MSejABSibOVNI2+O4zjks3vorbT7wXNIYzZzdO9KpudQbCrLeDLfKyJDCRclonJhX3dwIkvvn6KaG9R9cWBtCFiFfr05D9gXKKgzdfUfqfdKRREVerWRY9CKeFpAXqwjQDEt17ZxaUIGxGF5Nhk6kNA9bgYZmgsKqVZ4kIbRi3fDTEwolW44hVtWFBg22A== 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=bkzQ0gtS1i/YcNAitWSlGi8wxdbqXbLigyaecaghMz4=; b=l8zDZC1G17dEkO4kh+sTfAnJ7fyfNlF/sSr6HGdN0sRDthj9o+4fo8BLsgLe4nPLd4toDD6I1+f+cRdVwDH4WI8Ud5kF1UFEJO5R8LbXcvRi9nNPxlwofrGqpOJ5HzoAj+7xsFVWtwc7kDhIlo4GWwBlGVfEkViOUtZVILT9wOKOHJ5E7oBxtWjkU6j+XBMYeyqCogcOJ5WiupprN22izTn31gkNJyddNfoOzkd3IjBHPZRScuoi5rV0mjKtoSbNsehK0eNr87KXhPrvOeE0y+59p9ZJ9ERa37IrAbd+LS2wDx7jHGoBZ4ovQbYpRmEbcoEKJdlzPO6qi1fJ2t8Z/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; 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=bkzQ0gtS1i/YcNAitWSlGi8wxdbqXbLigyaecaghMz4=; b=iMD+1lD3ESaSpOH0jTLArTlO7MF2LuGH1aYablBOX0Bj+rcwmYy0sfOrJyKJLqogjjmARJ8ddTW/nReCrbSW0auC4Y90BTRX3d12xQ4V7M5M0b/VYlBglkdECcs+QLBj2TIhC0sp6W3rBW96P4e/oF/1ZN65HS2K042QAXx+6z2hOvCwXd5R5/qU+RsXlluNsWNiJtOSbsjflt6rngynSeqURW/L9wpjFFwiJvORSjKS+2I+t2utxwNmXZcVQtAtFmeRJVMWjPUoZ1NmG7RsSfdSIVhg/KN+m4tXNmLhmfmEfuC1RVXRZx3cN5OU8FwRnlfviduHj1R4bWzvlCNJjA== Received: from BY5PR12MB5544.namprd12.prod.outlook.com (2603:10b6:a03:1d9::22) by MN2PR12MB4157.namprd12.prod.outlook.com (2603:10b6:208:1db::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22; Sat, 26 Feb 2022 21:48:14 +0000 Received: from BY5PR12MB5544.namprd12.prod.outlook.com ([fe80::1cc3:2137:2949:b0a7]) by BY5PR12MB5544.namprd12.prod.outlook.com ([fe80::1cc3:2137:2949:b0a7%3]) with mapi id 15.20.5017.026; Sat, 26 Feb 2022 21:48:14 +0000 From: "Ashish Singhal" To: Marc Zyngier CC: "devel@edk2.groups.io" , "quic_llindhol@quicinc.com" , "ardb+tianocore@kernel.org" , "sami.mujawar@arm.com" Subject: Re: [PATCH v2] ArmPkg: Invalidate Instruction Cache On MMU Enable Thread-Topic: [PATCH v2] ArmPkg: Invalidate Instruction Cache On MMU Enable Thread-Index: AQHYKst6QKpOdXi4RUWQpgoiJ0nb3qymVzsAgAAGEiM= Date: Sat, 26 Feb 2022 21:48:14 +0000 Message-ID: References: <9f95ba0bb19fd034af27f4f564e5eeff0ec19fff.1645850486.git.ashishsingha@nvidia.com> <87zgmd5nth.wl-maz@kernel.org> In-Reply-To: <87zgmd5nth.wl-maz@kernel.org> Accept-Language: en-US X-Mentions: maz@kernel.org X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 73a67bb2-e2da-274d-fa56-53866f04def3 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9be7fb9c-db7d-457a-6c3f-08d9f971b0d0 x-ms-traffictypediagnostic: MN2PR12MB4157:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hkvpxHGEnsiIvUcZwHdXQkel4iYEkGrFF0q5WFW7qfUIpoCKrGCbTRdH1v/NNcimAXVx3mYnkSxuSl0PmKg+KLt4HbqYMvXf/rf3uBc35WGTUluKZ5K/xcxo99rOkUOAIv//UEQhOb/losNRxVJjiRcyfc0l6WAq+wqgJbl2Htu4MVriMOZzf9xajNwAghu2NGaSOH6InPgY8JYURd1AJe7OshV5KrTo3ygax8dGqSRRjIxzTulUyQ/rHP3XI3YYbHRoIV23Gf3tCrCxRYd2vj2wDx92ZiTonzdiGuwICogeN9ubyNQS2zoLYQU6b9R59FlYT6UxXfmzPvkTAbXVk+BwBMr7YXA2HuXxlDmha/tS0VLI9i8ZzKscRAFrx41oH8djAhAVm9WV5IAOZbFpOdXsNtDlBCarCcAFA48WfN1HHjmWEID71O5ceEOEtDRTBPTC4stG/DA3GwpdRk4ty48CQ9T3eX0fb8iOtQWGAanqZa/a3qHQG2KKiS9eTNtIsSfJFz/5sWU+3MuAj7oJimrBh6USIqLWccFfT3K4niDbMlxMgLfy5uw6hswKd0IW1YdDGTWtjBzSQJgLXUt+Xe9kzB6f9py8DBt3euGw/YwRChcPgYzA5FHBxvaBoHtGy+tmE9ekD0mki0zDD9qUgl9wi7vC9JAyuivXko+XfIk4hcUZM/3liW/AYNzeu13KV8EsU4VObHExS2amguA73A== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR12MB5544.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(122000001)(6916009)(54906003)(33656002)(66946007)(76116006)(55016003)(186003)(316002)(38100700002)(4326008)(8676002)(2906002)(8936002)(5660300002)(66446008)(86362001)(66476007)(64756008)(38070700005)(52536014)(66556008)(9686003)(53546011)(6506007)(7696005)(26005)(83380400001)(508600001)(71200400001)(19627405001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?pvT5922ubR4k1Spg/AEKrV2KM9jI1srCKIk2jv0wtNcoaa2xUMv1K9Sw?= =?Windows-1252?Q?iEzkVlPw6Hl12ksmsezXMXVA3En9xcweGEwaE/kolRZtptpHuzA3dCH3?= =?Windows-1252?Q?XAs3WgDVCNH58JcWrfMsFtib9QDDD437WOkwiHUX4wou/GXIRmNbdbDb?= =?Windows-1252?Q?CKs6SFNj68SV7gGCCXqYl32dF1A2e2McI+TADZSANHOU1rYcy6nuUOvD?= =?Windows-1252?Q?nthJ0CL9iCFg4eH8gRGs23pOjacmfvngXQzSfpcGKuX7JrpA0Opx94Wr?= =?Windows-1252?Q?juy3NSzJd2gPjOo5MfuKMIXCA1VW546LrRC265hB4rmj3T5DjKXQS8GM?= =?Windows-1252?Q?U2g+5IJ8owcyuj26DNsFCakrEy3FobylKBuM39rOZxDXuIrlfcW0q1gP?= =?Windows-1252?Q?bXEyrsjyDdMjsaMPKWY0kxnL32eag0YHn0Jvx1RL6oaRY5EDG0g4PQ67?= =?Windows-1252?Q?zYPhCCTalxE16QEHm6ZsFA7lL3pwmfZfBp2E01+dvnAys8jzVNjJcEt8?= =?Windows-1252?Q?g6NkAQdz4mIAPZqMKe7qYOBeb3Km3l7e+E2z1Co9Gi0KYRv+zGHxhZ4Z?= =?Windows-1252?Q?nH+X8oS7EHIOZtNKtHUypyfEu40D6NOw0Y2HX6HQnQtEISs8Nyu9epab?= =?Windows-1252?Q?jvJHfbWOWEImaIb++C2Oo9VNL9laX/xMpL/aIvXdXuLRtcy6P/rirKJk?= =?Windows-1252?Q?TWuiiB0/lx2JN3ulxpK8/onpPZXsyJcD7Y7OfsX1BHtekFDY3A7bAo8a?= =?Windows-1252?Q?zVHzFe5AaSi2Gd2RWT+cXEh6QGAbY+FDRmN6f7o0u0hyadxxpv6HiFIU?= =?Windows-1252?Q?XTfI2hKhkdgEYG380Cl9TZRkPoIlthCxTdFRzOihIqG4KHihCo/QFLFC?= =?Windows-1252?Q?6Ju3i23tyNPklQZDk33UMmp4/Dr5yhznsmQJ+uY4SHEvrLgBQcpVGG9c?= =?Windows-1252?Q?9uws785hVDfP9lwbBcqetwG4+pyzDDDUE15L9ktv9+XQ1dwMf8djeoDW?= =?Windows-1252?Q?QtYWw9tsODAPvYJvRN23qIiuRKl59ljLdE4fXKlc5aZPLjG+AxAsAWJ+?= =?Windows-1252?Q?PtUc4jIowDRH6pnfgkO31vHHEaAxSHHpX1soLKYO3n0ZiKNnlqeRsJXy?= =?Windows-1252?Q?25vzYwwWWv3zYnfEKGPVop/1tKDbs2mzapOK9Z5XWhs7dCd9aer6d78V?= =?Windows-1252?Q?MNou8zeZcmHBQP3OtOjBzqMbQd9U1jiSVtZa8AEfRjjP0qhByGrRVCdD?= =?Windows-1252?Q?CGcIjvwDLh6puZaITaFozTbeJYzGxJUSK77ZRZ65G3py6Wi+sp6cuNpK?= =?Windows-1252?Q?U4z3DvGHLVz7xJ7U9xXXbGGk6FEfJ7/U7yCkZ5EweDB5mghlvdfVbTLM?= =?Windows-1252?Q?kziujmLm/Dtitpy4Rpuq/WnduP6hR+eVTJNyW8H/e1+yXnGllJRXuM4u?= =?Windows-1252?Q?1b4sKPBANK26EDs95EVLAE33iVWwK3mXKN/HAL8C5xlEVdti3J2mYX1+?= =?Windows-1252?Q?DoU4DXIZ8ZtnsueQbCD+gPwwOy52k+hCpM4vvH7FkyJhVReLwxXThXxy?= =?Windows-1252?Q?8x4z+5Zt7cp5Y2DgdyoJH6iU2g1i6xjQ/0j7oOFw3DcV/jg0Rw0jhfux?= =?Windows-1252?Q?/f8yKLCmerTdPS/B/Cz11oaJK3KF29XyQqVeAOuf6JOrdG8991B8Xi7R?= =?Windows-1252?Q?/cAUXRxBybLqMhMFeZZZKDpQaQWtodzyigeBDZxNJCr3KEBV+Jak1Q?= =?Windows-1252?Q?=3D=3D?= MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB5544.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9be7fb9c-db7d-457a-6c3f-08d9f971b0d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2022 21:48:14.2080 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dq97QEthp+euPIjrKPr4RQmdtW03OOI1lAt252ZLzwcKu+NEnLt1kwmczW5WGWkxayz5OhRtI7AvgfBe5C1O+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4157 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BY5PR12MB554439190955893B21BF4A6EBA3F9BY5PR12MB5544namp_" --_000_BY5PR12MB554439190955893B21BF4A6EBA3F9BY5PR12MB5544namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable @Marc Zyngier Thanks for your response. I have provi= ded some comments inline. Please note that I am still not saying what I am = doing is a solution and I could still just be masking the problem at hand. = Please provide me with some suggestions that I can try for the problem bei= ng discussed on the email chain for the first version of this patch where y= ou are already there. Thanks Ashish ________________________________ From: Marc Zyngier Sent: Saturday, February 26, 2022 2:18 PM To: Ashish Singhal Cc: devel@edk2.groups.io ; quic_llindhol@quicinc.com = ; ardb+tianocore@kernel.org ; sami.mujawar@arm.com Subject: Re: [PATCH v2] ArmPkg: Invalidate Instruction Cache On MMU Enable External email: Use caution opening links or attachments On Sat, 26 Feb 2022 04:43:37 +0000, Ashish Singhal wrote: > > Even with MMU turned off, instruction cache can speculate > and fetch instructions. This can cause a crash if region > being executed has been modified recently. With this patch, Modified by what? [Singhal, Ashish]: Modified by MMU code in terms of their memory attributes= . > we ensure that instruction cache is invalidated right after > MMU has been enabled and any potentially stale instruction > fetched earlier has been discarded. > > This is specially helpful when the memory attributes of a > region in MMU are being changed and some instructions Changed from what to what else? Are you concerned with the content of the memory being changed? Or by the attribute being changed? Or both? [Singhal, Ashish]: I am concerned with the attributes being changed. UEFI drivers are dispatched in RWE memory and then memory attributes are changed to ROE for the code section and RWnE for the data section. > operating on the region are prefetched in the instruction > cache. I don't see how this fixes anything. Yes, speculation occurs. But if your icache contains crap, how is it safe to first enable the MMU first and then nuke the icache? You could well be executing garbage at that point. Worse case, and assuming that you have an aliasing VIVT icache, this will invalidate fetches that would alias with the layout of the memory once the MMU is on. But as far as I know, EDK2 is entirely identity mapped. I also don't think it uses instruction patching. Finally, if you see speculative accesses on regions that shouldn't be accessed as such, it could well be because the code is placed too close to such a region, as mentioned in the ARM ARM (DDI0487H_a, page D5-4828): Behavior of instruction fetches when all associated stages of translation are disabled [...] To ensure architectural compliance, software must ensure that both of the following apply: =95 Instructions that will be executed when all associated stages of address translation are disabled are located in blocks of the address space, of the translation granule size, that contain only memory that is tolerant to speculative accesses. =95 Each block of the address space, of the translation granule size, that immediately follows a similar block that holds instructions that will be executed when all associated stages address translation are disabled, contains only memory that is tolerant to speculative accesses. [Singhal, Ashish]: I do not think this is an issue here. Thanks, M -- Without deviation from the norm, progress is not possible. --_000_BY5PR12MB554439190955893B21BF4A6EBA3F9BY5PR12MB5544namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
@Marc Zyngier Thanks for you= r response. I have provided some comments inline. Please note that I am sti= ll not saying what I am doing is a solution and I could still just be masking the problem at hand.  Please provid= e me with some suggestions that I can try for the problem being discussed o= n the email chain for the first version of this patch where you are already= there.

Thanks
Ashish

From: Marc Zyngier <maz@= kernel.org>
Sent: Saturday, February 26, 2022 2:18 PM
To: Ashish Singhal <ashishsingha@nvidia.com>
Cc: devel@edk2.groups.io <devel@edk2.groups.io>; quic_llindhol= @quicinc.com <quic_llindhol@quicinc.com>; ardb+tianocore@kernel.org &= lt;ardb+tianocore@kernel.org>; sami.mujawar@arm.com <sami.mujawar@arm= .com>
Subject: Re: [PATCH v2] ArmPkg: Invalidate Instruction Cache On MMU = Enable
 
External email: Use caution opening links or attac= hments


On Sat, 26 Feb 2022 04:43:37 +0000,
Ashish Singhal <ashishsingha@nvidia.com> wrote:
>
> Even with MMU turned off, instruction cache can speculate
> and fetch instructions. This can cause a crash if region
> being executed has been modified recently. With this patch,

Modified by what?
[Singhal, Ashish]: Modified by MMU code in terms o= f their memory attributes.

> we ensure that instruction cache is invalidated right after
> MMU has been enabled and any potentially stale instruction
> fetched earlier has been discarded.
>
> This is specially helpful when the memory attributes of a
> region in MMU are being changed and some instructions

Changed from what to what else? Are you concerned with the content of
the memory being changed? Or by the attribute being changed? Or both?
[Singhal, Ashish]: I am concerned with the attr= ibutes being changed. UEFI
drivers are dispatched in RWE memory and then m= emory attributes are
changed to ROE for the code section and RWnE fo= r the data section.

> operating on the region are prefetched in the instruction
> cache.

I don't see how this fixes anything. Yes, speculation occurs. But if
your icache contains crap, how is it safe to first enable the MMU
first and then nuke the icache? You could well be executing garbage at
that point.

Worse case, and assuming that you have an aliasing VIVT icache, this
will invalidate fetches that would alias with the layout of the memory
once the MMU is on. But as far as I know, EDK2 is entirely identity
mapped. I also don't think it uses instruction patching.

Finally, if you see speculative accesses on regions that shouldn't be
accessed as such, it could well be because the code is placed too
close to such a region, as mentioned in the ARM ARM (DDI0487H_a, page
D5-4828):

<quote>
Behavior of instruction fetches when all associated stages of
translation are disabled

[...]

To ensure architectural compliance, software must ensure that both of
the following apply:

=95 Instructions that will be executed when all associated stages of
  address translation are disabled are located in blocks of the
  address space, of the translation granule size, that contain only   memory that is tolerant to speculative accesses.

=95 Each block of the address space, of the translation granule size,
  that immediately follows a similar block that holds instructions
  that will be executed when all associated stages address translation=
  are disabled, contains only memory that is tolerant to speculative   accesses.
</quote>

[Singhal, Ashish]: I do not think this is an issue here.

Thanks,

        M

--
Without deviation from the norm, progress is not possible.
--_000_BY5PR12MB554439190955893B21BF4A6EBA3F9BY5PR12MB5544namp_--