From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail04.groups.io (mail04.groups.io [45.79.224.9]) by spool.mail.gandi.net (Postfix) with ESMTPS id 33C3AD8042C for ; Wed, 17 Apr 2024 21:41:50 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=PToBS7tPcRUEHkCVULuBK40t6fIRFqET6pBq4DTGwpM=; 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=1713390109; v=1; b=qGPUJpLBY7oD3tjo36xt1L1Rr2TdABAkW8kBMbgvSJL7/6M5K2joCng4MpU0WRr8eo067FT+ BBxvxgqyQIaggxwLa9Mo5veY7YdjpsKspHIoN8iJMvabMYkUjWQMi27rbxH2/PqPINh5t4dlTFS IUpubwom3wtgeWLdaP6hlxkBr55IxGKS+shUnRVOqA+QdP/rAre7hVU4F3aJiMFlTFKpH5TQnOG ikNi/lqWJOn0LBqwpl9WrTw8ksf5vf3TgQB2sVsKqobL2rNuEtd8IlQATBHK2CyFplh4F5cUPYf mAssdDRFL5YplboVK4Csyawl4EM5sFB5sDQZoP55ClfAA== X-Received: by 127.0.0.2 with SMTP id T3R8YY7687511xEWCTnNJvRM; Wed, 17 Apr 2024 14:41:49 -0700 X-Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web11.295.1713390109062044328 for ; Wed, 17 Apr 2024 14:41:49 -0700 X-Received: from [10.137.194.171] (unknown [131.107.159.43]) by linux.microsoft.com (Postfix) with ESMTPSA id 8B73920FD470; Wed, 17 Apr 2024 14:41:48 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8B73920FD470 Message-ID: Date: Wed, 17 Apr 2024 14:41:48 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] [PATCH v1] MdeModulePkg: Fixup MAT Attributes After Splitting EFI Memory Map To: Taylor Beebe , devel@edk2.groups.io, ardb@kernel.org Cc: Liming Gao References: <20240417022836.1593-1-taylor.d.beebe@gmail.com> <2644bcd1-29c7-4cc0-9600-ae2a2eca9927@gmail.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: Wed, 17 Apr 2024 14:41:49 -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: yWhomkm5oL1wHdI2KevUI5zlx7686176AA= 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=qGPUJpLB; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.9 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=linux.microsoft.com (policy=none) On 4/17/2024 7:34 AM, Taylor Beebe wrote: >=20 > On 4/17/2024 7:09 AM, Oliver Smith-Denny wrote: >> On 4/17/2024 7:05 AM, Taylor Beebe wrote: >>> >>> On 4/17/2024 6:40 AM, Oliver Smith-Denny wrote: >>>> Aside from this, I wonder if we can be more aspirational here. These >>>> EfiRuntimeServicesCode regions without attributes set are, if I am >>>> understanding correctly, from loaded images.=20 >>> These EfiRuntimeServicesCode regions without attributes set are >>> not part of loaded image memory. I think that's what you meant but >>> wanted to clarify. >> >> Are these regions without attributes from image sections that have >> been padded to RUNTIME_PAGE_ALLOCATION_GRANULARITY, i.e. they are >> the pads? Or are we saying we don't know what these regions are >> at this point? It is true in theory someone could just allocate >> an EfiRuntimeServicesCode section. > Good question -- I had not considered the extra padding applied > to these allocations. It could be either. The memory map returned > via GetMemoryMap() will merge descriptors together based on type > so it's possible to mistake an unrelated EfiRuntimeServicesCode > allocation with padding applied to a runtime image memory > allocation if they are contiguous. Taylor and I had an offline conversation and checked on this, my recent patch moving ImagePropertiesRecordLib to use VirtualSize instead of SizeOfRawData fixed this. So we should not see any padding sections as without attributes. Now, for the case of ARM64, where you have 64k runtime granularity and often will end up with the case of many extra pages in a code section, those pages will be marked as RO and executable, even though they contain garbage. I think it would be worthwhile to mark the excess garbage pages, if they exist for a given section, as RP. Nothing should be using them in any fashion, they are padding. 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 (#117934): https://edk2.groups.io/g/devel/message/117934 Mute This Topic: https://groups.io/mt/105570114/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-