From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by mx.groups.io with SMTP id smtpd.web10.1754.1689196802748487860
 for <devel@edk2.groups.io>;
 Wed, 12 Jul 2023 14:20:02 -0700
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@linux.microsoft.com header.s=default header.b=JJoZTD8T;
 spf=pass (domain: linux.microsoft.com, ip: 13.77.154.182, mailfrom: osde@linux.microsoft.com)
Received: from [10.137.194.171] (unknown [131.107.1.171])
	by linux.microsoft.com (Postfix) with ESMTPSA id 9749C21C44E3;
	Wed, 12 Jul 2023 14:20:01 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9749C21C44E3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
	s=default; t=1689196801;
	bh=ZJ4sPf1/P+qfEwcTnVNzWnMzTKRfeXLrPlGacu7gso8=;
	h=Date:Subject:To:References:From:In-Reply-To:From;
	b=JJoZTD8TduSrDNlw11KgfULepaRUb6W4S/zn9f1ys0HRov7lpot1noAR1w7RVDl4n
	 IFhwQSkszx17Hxo/1Sc3gCIMtB3LmQy4P7KXV4GUgX/h5txMGMGKj+vU7QLysDIfrf
	 oVxxPYjazfmkEU7+ddcupEArR3GKac62844CiRtc=
Message-ID: <6c651b18-4533-9071-9a57-76faca746c7f@linux.microsoft.com>
Date: Wed, 12 Jul 2023 14:20:01 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [edk2-devel] heap/page guard broken on aarch64
To: devel@edk2.groups.io, kraxel@redhat.com, Ard Biesheuvel <ardb@kernel.org>
References: <uohzj3bb2n2fhmojdol5p4v2mfslvavr3ntjufe3ll26h5xn5y@baa37hrbeccr>
 <CAMj1kXHszFoXUAzjP1ydewh1sSxBDyS8qDBMo7gN121c+e4Sgg@mail.gmail.com>
 <uylhozyupscbpjqco5mgnyrmeceobhbhl5vxw5mrbrglq2aefl@dhyp6xzioho7>
From: "Oliver Smith-Denny" <osde@linux.microsoft.com>
In-Reply-To: <uylhozyupscbpjqco5mgnyrmeceobhbhl5vxw5mrbrglq2aefl@dhyp6xzioho7>
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 7/12/2023 6:26 AM, Gerd Hoffmann wrote:
> On Wed, Jul 12, 2023 at 02:03:37PM +0200, Ard Biesheuvel wrote:
>> On Wed, 12 Jul 2023 at 10:41, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>>
>>>          PcdHeapGuardPageType=0x7e
>>>          PcdHeapGuardPoolType=0x7e
> 
>> This looks like the debug 'poison' value is applied to the freed guard
>> page before the EFI_MEMORY_RP permission is removed.
>>
>> I wonder if the 'IsGuarded' logic in CoreFreePoolI is wrong here: this
>> is runtime memory, which is rounded up to 64k granularity on AArch64,
>> and I would not be surprised if that code is buggy.
> 
> Looks plausible to me.  Tried fix AdjustPoolHeadF() to use granularity
> instead of efi page size, that alone didn't make the firmware boot
> though.
> 
> Clearing the two runtime memory type bits (0x7e -> 0x1e) makes the
> firmware boot.

I haven't had a chance to look at this further yet, but this seems
related to an issue I saw, where legitimate EFI_MEMORY_RP pages will
crash in CoreFreePoolI on release builds, because we don't clear
EFI_MEMORY_RP and that function attempts to read the page (on debug
builds, we do set the DEBUG_CLEAR_MEMORY bit and so clear
EFI_MEMORY_RP before the pool mgmt code tries to read it).

Likely, we should be clearing EFI_MEMORY_RP from pool managed memory
in all cases. It is an odd use case and I was debugging a different
bug that was causing memory to accidentally get marked EFI_MEMORY_RP,
but still, it seems to be a latent bug.

Thanks,
Oliver