From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 466931A1EEE for ; Wed, 21 Sep 2016 09:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jXFGrIst3xVuNMpDWlcNFyI77MPeZew29b47gY2EJTs=; b=UEUMjaGQGIRJbPZ71ISnO7nC4P+fjBjBReMYFSN+p2OaCdVWN6sPgYJwFhuYRCViqotP5e9rmKKoxWYUFPm5OwajO4eHd2fxbfCT6Po4ESaestN+HreWV/KXnLFuZZSW7MZJF8m4f4ItCFQ332adYgmWJtSp8DtXBOnGcbFQI/8= Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Wed, 21 Sep 2016 16:09:06 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0629.015; Wed, 21 Sep 2016 16:09:06 +0000 From: Kurt Kennett To: edk2-devel Thread-Topic: Problem with Arm Mmu code in CpuDxe Thread-Index: AdIUH0dOvWRvTCziSOGQVEzTYgevSw== Date: Wed, 21 Sep 2016 16:09:06 +0000 Message-ID: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kurt.Kennett@microsoft.com; x-originating-ip: [2001:4898:80e8:2::25d] x-ms-office365-filtering-correlation-id: 2d5ecbf5-812d-4306-4c0d-08d3e2399d52 x-microsoft-exchange-diagnostics: 1; BL2PR03MB433; 6:juek8dg7+z25FobP8ht+ytwliv+WwkfDn6cKvk/Xdh7bYdG0ucKjtMQIArQDTnrZYSBlEIpDUuEufPpz7BVEn+14JTApk3pq0TYYZx2ycwR/mAxIcGcfpi3tH11jeLxgNn9otJxRZ1SR/w03dNHRsjEJSlBoYmQ91Em+P3UoUosU/Ka7BhaBX7rtgSe+Jza+/znL9ev9k8Ulf7G4TIKh+XZ/wzD4T9HHwy77GfRq2R795JZMo6iR9sXpZi+8bbQ8nQZitge1WS0heZW+13s2JetukHbJEnsq7HZtGoMWSxR8Zu75wfhPZims3MryKFGV2NtXTiR1RcQjcC6/ww7dvg==; 5:4KMlE1Ikgg8SLPP2nasOZvqxlp2SQlSwBay2vlR4BE7W3Lysw9HeSkWjrUs/QbJlvmJAmJ4vHuZeY+yPeOWcqFD2ubrdixPrVBR/zFeoyjUgQqXOsFxRLGZGpio6jC1A7Yp/3dC+oL2c2CRYe9Ha0A==; 24:+VgOLueg76dwWRO/nvCAGYAZF6Jb38WtpEzFe4o9At/IqasXGpxZFfmXARuyS5pXl7fs6vZDSWjJ29GCOTulQuIloJHz8MQ0VfP+vpvEBwE=; 7:/PH/oL75jTGvigX6pVXMCBWeMXQW4fjo34UIYwhjnG1qko1IykMejPxFnRc9KEaoRhHl9d2BSkQs25CQ3lbkvgD7kuC6n1FwFRmtGdiRD11ftHYR8fFS3mKfi2LrYSlupjYCnk/WLxNybY0zmz/L7bFCTjmjRuc5ZSt59BfFkvziFTzPkiNswZNIyWfJERb1cmwoTXc6I1meU9APZU5GrKi/iBlOuOaEFIFgkM/9zC0m93Iu5fa5e5XRcq//tSH48yjl+oWDApbwhCuBjUBobH5HNe/ARwEfpF2GkMt40uQ8mYwU0Gl5uhJevShjsmOQ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB433; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BL2PR03MB433; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB433; x-forefront-prvs: 007271867D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(87936001)(2906002)(101416001)(19300405004)(19625215002)(9686002)(5660300001)(68736007)(92566002)(122556002)(10090500001)(74316002)(5005710100001)(10400500002)(10290500002)(229853001)(3280700002)(7696004)(3660700001)(7736002)(7846002)(110136003)(107886002)(16236675004)(54356999)(50986999)(33656002)(99286002)(106356001)(105586002)(86612001)(189998001)(8990500004)(97736004)(586003)(575784001)(76576001)(86362001)(19580395003)(81166006)(81156014)(450100001)(102836003)(790700001)(6116002)(77096005)(15975445007)(2900100001)(11100500001)(8676002)(8936002)(5002640100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB433; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2016 16:09:06.8460 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB433 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Problem with Arm Mmu code in CpuDxe X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 16:09:08 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am having a problem on my system (assert), and during investigation I may= have found a problem with the Arm CpuDxe Mmu code that may affect all ARM = platform users. CpuDxeInitialize is the entry point, and pretty soon after entry it does: SyncCacheConfig (&mCpu); This calls into: ArmPkg\Drivers\CpuDxe\Arm\Mmu.c The code asserts that the Mmu is enabled, gets the memory space map, then s= tarts to process the page tables by getting the TTBR0 base address. // obtain page table base FirstLevelTable =3D (ARM_FIRST_LEVEL_DESCRIPTOR *)(ArmGetTTBR0BaseAddress= ()); // Get the first region NextSectionAttributes =3D FirstLevelTable[0] & (TT_DESCRIPTOR_SECTION_CAC= HE_POLICY_MASK | TT_DESCRIPTOR_SECTION_AP_MASK); // iterate through each 1MB descriptor NextRegionBase =3D NextRegionLength =3D 0; for (i=3D0; i < TRANSLATION_TABLE_SECTION_COUNT; i++) { if ((FirstLevelTable[i] & TT_DESCRIPTOR_SECTION_TYPE_MASK) =3D=3D TT_DE= SCRIPTOR_SECTION_TYPE_SECTION) { ... } else if (TT_DESCRIPTOR_SECTION_TYPE_IS_PAGE_TABLE(FirstLevelTable[i])= ) { Status =3D SyncCacheConfigPage ( i,FirstLevelTable[i], NumberOfDescriptors, MemorySpaceMap, &NextRegionBase,&NextRegionLength,&NextSectionAttributes); ASSERT_EFI_ERROR (Status); } else { Note that the "NextSectionAttributes" is computed based on the assumption t= hat the entry is indeed a section, and not a first-level pagetable entry. = The cache policy mask and ap mask have no meaning for a pagetable entry. Assume my TTBR0 points to 0x80000000 and the very first entry in the transl= ation table is 0x4FFEB009. Decoding this entry gives: Entry is a Page table (low bits 01) NS is 1 (Not Secure) Domain is 0 Page table base address is 0x4FFEB000 But the 'NextSectionAttributes' computed above is 0xB000 (again, which is g= arbage since the entry is a page table not a section). Above, the system calls SyncCacheConfigPage, with the 'NextSectionAttribute= s' address, which leads to: // Convert SectionAttributes into PageAttributes NextPageAttributes =3D TT_DESCRIPTOR_CONVERT_TO_PAGE_CACHE_POLICY(*NextSectionAttributes,0) = | TT_DESCRIPTOR_CONVERT_TO_PAGE_AP(*NextSectionAttributes); >>From 0xB000, this creates page attributes which are invalid. The code then follows: for (i=3D0; i < TRANSLATION_TABLE_PAGE_COUNT; i++) { if ((SecondLevelTable[i] & TT_DESCRIPTOR_PAGE_TYPE_MASK) =3D=3D TT_DESC= RIPTOR_PAGE_TYPE_PAGE) { // extract attributes (cacheability and permissions) PageAttributes =3D SecondLevelTable[i] & (TT_DESCRIPTOR_PAGE_CACHE_PO= LICY_MASK | TT_DESCRIPTOR_PAGE_AP_MASK); if (NextPageAttributes =3D=3D 0) { ... } else if (PageAttributes !=3D NextPageAttributes) { // Convert Section Attributes into GCD Attributes Status =3D PageToGcdAttributes (NextPageAttributes, &GcdAttributes)= ; ASSERT_EFI_ERROR (Status); ... } } else if (NextPageAttributes !=3D 0) { Assume the second level descriptor is something harmless like 0x00000072. 00000072 =3D Small Page, NX clear C =3D 0, B =3D 0, TEX =3D 001, so Outer and Inner Non-cacheable Normal M= emory AP =3D 011, so Read/Write for both Priviledged and User Physical page address 00000000 This is at least something different from 'NextPageAttributes' (which is no= t zero) This leads to "convert section attributes into gcd attributes" a call to Pa= geToGcdAttributes with the (invalid) NextPageAttributes. The code does: switch(PageAttributes & TT_DESCRIPTOR_PAGE_CACHE_POLICY_MASK) { Which results in an unknown cache policy, and the function returns EFU_UNSU= PPORTED. This causes an ASSERT. I was investigating a fix but at the same time wanted to let the mailing li= st chime in on whether anyone else had run into this problem or had ideas o= n the proper way to solve it. K2