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.web10.13569.1678977066965717223 for ; Thu, 16 Mar 2023 07:31:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FrhYfiDB; 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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6B60C6205E for ; Thu, 16 Mar 2023 14:31:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53E0DC4339E for ; Thu, 16 Mar 2023 14:31:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678977065; bh=N7MGXjN6cMlODiNhlTvaXaZU3Vt+41z3YoVnKdJFlAM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FrhYfiDBzC6beXJDrMxOTm/D8CBH2RMa4XsVNVZWRAvGtEaocVcjJSnRUq5fROWq2 Bq0QGNVBzva8DLq4SwXFskMXKQYqaYHTf13vc5L/kP+E0TnUPEBRHP0BU6zcL1ZhxE YNk24bapBw2bAFY0RxhxuEhgJ7ueJvVnyKDBDEbx7AkL+cMVIgPdq28C17YMt7cAPP aNi1mPbxtujie96MVFc44vDMf921pVlggDKhVJjj0e5G6Amvj+6nsBzj1nmkrDvjAv vADJ9Qtuv8gPvJHKHpjm7J5IEJ6ZwtyshhVod+SR57ojmNGJ5RkOHf2zyZMlUqiAbr LMFxSG4vYAAOg== Received: by mail-lf1-f54.google.com with SMTP id x17so2633486lfu.5 for ; Thu, 16 Mar 2023 07:31:05 -0700 (PDT) X-Gm-Message-State: AO0yUKX6rphHo4mE2/EHuoC9oqQg0bEnkvzs2W6u+x0D45/glndYikKA VK/uaEya/apaqm6h7yE2+SgOcJrJ/aujBhl9K7w= X-Google-Smtp-Source: AK7set+t8Zar2HUud0ubqt+cEh+u+iL9BAuQW3CQagVmTEY470yfyx2P8l+VLDUD/6vTUdWH5AjkmFl7lED9LZHjU5A= X-Received: by 2002:a05:6512:304c:b0:4dc:7e56:9839 with SMTP id b12-20020a056512304c00b004dc7e569839mr4978310lfb.5.1678977063266; Thu, 16 Mar 2023 07:31:03 -0700 (PDT) MIME-Version: 1.0 References: <20230313171714.3866151-1-ardb@kernel.org> <20230313171714.3866151-28-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Thu, 16 Mar 2023 15:30:52 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v5 27/38] BaseTools/GccBase AARCH64: Avoid page sharing between code and data To: devel@edk2.groups.io, quic_llindhol@quicinc.com Cc: Michael Kinney , Liming Gao , Jiewen Yao , Michael Kubacki , Sean Brogan , Rebecca Cran , Sami Mujawar , Taylor Beebe Content-Type: text/plain; charset="UTF-8" On Thu, 16 Mar 2023 at 14:46, Leif Lindholm wrote: > > On Mon, Mar 13, 2023 at 18:17:03 +0100, Ard Biesheuvel wrote: > > The AArch64 ARM architecture supports a hardware enforcement mode for > > mutual exclusion between code and data: any page that is mapped writable > > is implicitly non-executable as well. > > > > This means that remapping part of a runtime image for reapplying > > relocation fixups may result in any code sharing the same page to lose > > its executable permissions. > > > > Let's avoid this, by moving all quantities that are subject to > > relocation fixups to a separate page if the build is using 64k section > > alignment, which is only the case when building a runtime driver for > > AArch64. > > > > Signed-off-by: Ard Biesheuvel > > --- > > BaseTools/Scripts/GccBase.lds | 13 +++++++++++-- > > 1 file changed, 11 insertions(+), 2 deletions(-) > > > > diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds > > index 83cebd29d599..63e097e0727c 100644 > > --- a/BaseTools/Scripts/GccBase.lds > > +++ b/BaseTools/Scripts/GccBase.lds > > @@ -21,9 +21,8 @@ SECTIONS { > > . = PECOFF_HEADER_SIZE; > > > > .text : ALIGN(CONSTANT(COMMONPAGESIZE)) { > > - *(.text .text.* .stub .gnu.linkonce.t.*) > > + *(.text .text.* .stub .gnu.linkonce.t.* .plt) > > *(.rodata .rodata.* .gnu.linkonce.r.*) > > - *(.got .got.*) > > > > /* > > * The contents of AutoGen.c files are mostly constant from the POV of the > > @@ -34,6 +33,16 @@ SECTIONS { > > * emitted GUIDs here. > > */ > > *:AutoGen.obj(.data.g*Guid) > > + > > + /* > > + * AArch64 runtime drivers use 64k alignment, and may run in a mode where > > Hmm ... is this strictly speaking true? > I.e., yes, all 4k pages within a 64k page need to share the same > permissions, but that could arguably be provided by pooling 4k > allocations together for multiple runtime drivers? > That only works for dynamic allocations. The static allocations are all part of the PE/COFF image, whose size needs to be a multiple of the section alignment. If we decide we don't care about the image base and size after loading the image (which is reasonable, and TE is based on this notion as well), we could free the leading and trailing memory that we don't actually use after dispatching the image. *However*, the code section, which sits in between those, will always need to be a multiple of 64k, as it will be mapped with R-X permissions under the OS. This change only ensures that *within* that region, the relocatable quantities that may need to be rewritten when SetVirtualAddressMap() is called don't share a 4k page with executable instructions, as those would then lose their exec permissions under WXN. > Will this alignment constraint conflict with that, or just help > enforce the mapping compatibility? > > / > Leif > > > + * mutual exclusion of RO and XP mappings are hardware enforced. In such > > + * cases, the input sections below, which carry any quantities that are > > + * subject to relocation fixups at runtime, must not share a 4 KiB page > > + * with any code content. > > + */ > > + . = ALIGN(CONSTANT(COMMONPAGESIZE) > 0x1000 ? 0x1000 : 0x20); > > + *(.got .got.* .data.rel.ro) > > } > > > > /* > > -- > > 2.39.2 > > > > > > > > > > > > > > > > >