From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id 282EE7803D8 for ; Tue, 23 Apr 2024 14:33:45 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=1NAyg6jDr1m3OVQ+rY6Q0qmAzePHHs6OUiAMeM+rMec=; c=relaxed/simple; d=groups.io; h=DKIM-Filter:Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20240206; t=1713882823; v=1; b=lmiPXIOIasS7iGc0b/9cwcm+V77oMJhprSJZwc/Nmeec4A5kdZstd4Xhjje2r42AwYOzAemh GbF8fsN5Ox+CfuuVzaRaG9q7JeiSYacwcKBYwU6w9aaMPqdyaen+eCHI16EM1iy3sg5YXHuetdO xzAtulV3sqAgIfZdSJRn+DAPjO2xAHnBQJQFp+KW5HAGq3I0SvhBF/dfBFENPSDICRagHohgEcx G3DrhjWzyOfWlkGxm4hEdHHZGme7thuBplFURTMgMUdQFJIcheOiFRgiUC0mOB1Ql8UVX6GAHpn ikphODsgc0UXsxM8oBTssbUN8nh7JzUZ6HnguiL0G5y4g== X-Received: by 127.0.0.2 with SMTP id 0vrOYY7687511xtvL6Trs1MB; Tue, 23 Apr 2024 07:33:43 -0700 X-Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web10.20203.1713882822845240935 for ; Tue, 23 Apr 2024 07:33:42 -0700 X-Received: from [10.137.194.171] (unknown [131.107.159.43]) by linux.microsoft.com (Postfix) with ESMTPSA id 9FBF420FFC03; Tue, 23 Apr 2024 07:33:41 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9FBF420FFC03 Message-ID: <34e43fbc-e51a-4f7c-918f-d8daac74af4f@linux.microsoft.com> Date: Tue, 23 Apr 2024 07:33:41 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] MdeModulePkg: Fix MAT SplitRecord() Logic introduce one bug and will cause SUT reset when boot to windows To: "Ni, Ray" , "devel@edk2.groups.io" , "Huang, Yanbo" , Ard Biesheuvel , "Bi, Dandan" Cc: Taylor Beebe , "Wang, Jian J" , "Gao, Liming" , "Zhou, Jianfeng" References: <20231127181818.411-1-taylor.d.beebe@gmail.com> <45b9b2a8-4bbb-4d67-94a9-6c6d6607feb7@gmail.com> <045edd40-88e7-4af2-ab15-61aa8701f9a4@gmail.com> <140baa4f-b082-4121-bc34-7c03002d8de6@gmail.com> <6a542022-335d-4de3-95c6-6f04c9bbb370@linux.microsoft.com> From: "Oliver Smith-Denny" In-Reply-To: Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Tue, 23 Apr 2024 07:33:42 -0700 Resent-From: osde@linux.microsoft.com Reply-To: devel@edk2.groups.io,osde@linux.microsoft.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: oXH1d4wMCmKtqS8X6grLQrenx7686176AA= Content-Language: en-CA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=lmiPXIOI; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=linux.microsoft.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io On 4/18/2024 11:43 PM, Ni, Ray wrote: >=20 >=20 > So this is just junk unallocated memory that we are reporting as > a type it *could* be if an allocation occurs to minimize failures > of ExitBootServices. Which is questionable. But in terms of > attributes, I would expect we either have this unallocated > memory marked the same as the bin type or better, mark it RP > if we can (Taylor is making a change to set RP on free memory > by default, so we would have this in the page table, but we > would need to decide what we tell the OS). >=20 > [Ray] When reviewing today's logic of memory protection through page=20 > table, I feel that it was designed improperly in the beginning. > My rough thought is: > * All memory is RP initially (as you said Taylor will do that) Correct, Taylor is working on a change here and actually taking this a step further, that all free memory will be RP, to catch any use after free and keep a safer environment. > * Allocated memory is mapped as either RO or XD, depending=C2=A0on code/d= ata.=20 > Or RP if it's a guard page. This is mostly true, of course it depends on how the memory protections are configured. I would like to see this go to not being an option but something that DxeCore enforces by default depending on memory type allocated. >=20 > Maybe I am not aware of some limitations of the above idea. The=20 > limitations prevented the initial design be in this way. > Or what Taylor will do aligns to the idea? >=20 The issue in this mailing thread is not what DXE's page tables are, but what get reported in the MAT to the OS. Before Taylor's change to improve the SplitTable logic the extra RuntimeServicesCode sections that get reported to the OS (these are the leftover sections in the memory bins to improve the chance for S4 resume) were getting reported as XP. Taylor is proposing these get marked RO instead as they are marked as Code sections (although they really hold junk in them). Another path would be can we mark them both RO and XP. These are junk sections, they should not be used and definitely not executed from. We only report them to the OS so that our memory map changes less between boots (I also wonder if there are better ways we can do this, but I'll have to think about this more). Thanks, Oliver -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118143): https://edk2.groups.io/g/devel/message/118143 Mute This Topic: https://groups.io/mt/105477564/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-