From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.5634.1689163432715146649 for ; Wed, 12 Jul 2023 05:03:52 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kvRUhTbM; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2203161788 for ; Wed, 12 Jul 2023 12:03:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 871B6C433C7 for ; Wed, 12 Jul 2023 12:03:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689163431; bh=B8k6JRUXdEAZRN4QE85i7+Q8Gr3p0R5oPX84Q1GfW1U=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kvRUhTbMeUbe5zjC4+7nKgQsyWveTfgkjrrPPqZ5qWM/qUII1++X4GbZfqV7hfHWl Cyag8ngNGtjz0t+D6cR/TKqtincxZzTCh7rnaZjNYa77iXCnzxsSpno0BaDACt9edS LMHEBwnLCztEnXjkWnDsoVptj+t5/gYpHynkjMQcj7HbHE7zVjSHi3XgtLekQbR7dB /C8FBHJjuHm5hmsDS7w7tROKwLqvgNCwpsUhrhR03JrDPaq3Jbil30zgzhJhFCp23L L02N7+QDE6kQ7/HGHsNnWGwuTtPqlYMqXTYMJftQ6Ca5V+bpVsGuv9yxtxanAAdTfy ZSTDLNtF2vRkw== Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2b734aea34aso19546071fa.0 for ; Wed, 12 Jul 2023 05:03:51 -0700 (PDT) X-Gm-Message-State: ABy/qLYmHzuHOCGX2SzA33folMzTDRE8XEYSVWFPt5GvRwg7c2wOZh8T 6uca5kUoXAdTTq37nx7rVOyxNTMmbxY5wTzyAXw= X-Google-Smtp-Source: APBJJlGxTaFr6Xv3CI/GV6Ugr5wrGqUCEgU/2ZjlX7PFPSPUrGvjyEM+JXrxXzfEFjN8skljQaBoWMJAJAKJZcEDL7A= X-Received: by 2002:a2e:3c0a:0:b0:2b6:d77b:92b8 with SMTP id j10-20020a2e3c0a000000b002b6d77b92b8mr15514307lja.16.1689163429535; Wed, 12 Jul 2023 05:03:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 12 Jul 2023 14:03:37 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: heap/page guard broken on aarch64 To: Gerd Hoffmann Cc: devel@edk2.groups.io Content-Type: text/plain; charset="UTF-8" On Wed, 12 Jul 2023 at 10:41, Gerd Hoffmann wrote: > > Hi, > > Tried to debug a bug which looks like memory corruption, turned on page > and heap guard: > > PcdHeapGuardPageType=0x7e > PcdHeapGuardPoolType=0x7e > PcdHeapGuardPropertyMask=0x03 > > With that the firmware crashes due to a page fault. > > Stack trace (with PCs manually mapped to functions): > > PC 0x000047730268 (0x000047711000+0x0001F268) [ 0] DxeCore.dll -> InternalMemSetMem > PC 0x00004771F4EC (0x000047711000+0x0000E4EC) [ 0] DxeCore.dll -> CoreConvertPagesEx > PC 0x00004771FED4 (0x000047711000+0x0000EED4) [ 0] DxeCore.dll -> CoreFreePoolPagesI > PC 0x000047721368 (0x000047711000+0x00010368) [ 0] DxeCore.dll -> CoreFreePoolI > PC 0x000047721564 (0x000047711000+0x00010564) [ 0] DxeCore.dll -> CoreInternalFreePool > PC 0x00004772160C (0x000047711000+0x0001060C) [ 0] DxeCore.dll -> CoreFreePool > PC 0x00007C574338 (0x00007C560000+0x00014338) [ 1] VariableRuntimeDxe.dll -> FreePool > PC 0x00007C574F8C (0x00007C560000+0x00014F8C) [ 1] VariableRuntimeDxe.dll -> ReallocateRuntimePool > PC 0x00007C574FE0 (0x00007C560000+0x00014FE0) [ 1] VariableRuntimeDxe.dll -> VarCheckAddTableEntry > PC 0x00007C575FF0 (0x00007C560000+0x00015FF0) [ 1] VariableRuntimeDxe.dll -> VarCheckLibVariablePropertySet > PC 0x00007C5760B8 (0x00007C560000+0x000160B8) [ 1] VariableRuntimeDxe.dll -> VarCheckUefiLibNullClassConstructor > PC 0x00007C578828 (0x00007C560000+0x00018828) [ 1] VariableRuntimeDxe.dll -> _ModuleEntryPoint > PC 0x000047718788 (0x000047711000+0x00007788) [ 2] DxeCore.dll -> CoreStartImage > PC 0x000047725CC8 (0x000047711000+0x00014CC8) [ 2] DxeCore.dll -> CoreDispatcher > PC 0x00004771BFF0 (0x000047711000+0x0000AFF0) [ 2] DxeCore.dll -> _ModuleEntryPoint > > Some debug logging added shows that the faulting address is right after > the memory block which gets freed, looks like the code tries to clear > the guard page ... > > edk2-stable202305 is broken. > edk2-stable202302 works. > Trying to bisect did not work due to another bug. > 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. I'll dig a bit deeper - thanks for the report