From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by mx.groups.io with SMTP id smtpd.web10.12457.1678974407275248387 for ; Thu, 16 Mar 2023 06:46:47 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=KjqW3xJA; spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: quicinc.com, ip: 205.220.180.131, mailfrom: quic_llindhol@quicinc.com) Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 32GB88e3029597; Thu, 16 Mar 2023 13:46:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=qcppdkim1; bh=onWF0oftDJkG3hRzOuSme/xTcolbq5Eg5Pngzk+mYAg=; b=KjqW3xJAlj91KeWr9Blu4Fg5SiyM57c5nW7EABiQ6oC/4clK81PU++MWUQxiDcupdUt7 1vAaOAN6wJ3UeZEtvSwT7emZox1Z0ZkTJ6W3lHruQDnWGIw3eMwBFBeMNpHwvTOnS/Si iMVAv5onI6lwDK1nKCwxUCMFujGCK7ezAUXg5zM/NwqeN2Hchvy9gyJ5aqVy6I/TqAUV NeLEvcFkDJKR3yaOkx5c1d6aSWWbJuvXcD+QsnQmImeLZcPURloodbplj8B64b+Y2lAw jFRDrY0G9iIqb9YHTKuVO53Uw5juJrp4l/fCs5IMiw/hoB6gB6rZHkgGJ8wKpzH6WEIi LA== Received: from nasanppmta01.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3pbpy3hyws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Mar 2023 13:46:37 +0000 Received: from nasanex01c.na.qualcomm.com (nasanex01c.na.qualcomm.com [10.45.79.139]) by NASANPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 32GDka2D003366 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Mar 2023 13:46:36 GMT Received: from qc-i7.hemma.eciton.net (10.80.80.8) by nasanex01c.na.qualcomm.com (10.45.79.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.41; Thu, 16 Mar 2023 06:46:33 -0700 Date: Thu, 16 Mar 2023 13:46:30 +0000 From: "Leif Lindholm" To: , CC: Michael Kinney , Liming Gao , Jiewen Yao , Michael Kubacki , Sean Brogan , Rebecca Cran , Sami Mujawar , Taylor Beebe Subject: Re: [edk2-devel] [PATCH v5 27/38] BaseTools/GccBase AARCH64: Avoid page sharing between code and data Message-ID: References: <20230313171714.3866151-1-ardb@kernel.org> <20230313171714.3866151-28-ardb@kernel.org> MIME-Version: 1.0 In-Reply-To: <20230313171714.3866151-28-ardb@kernel.org> X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01c.na.qualcomm.com (10.45.79.139) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: tiopqK5P89Y2UO3itv4K-Kxhl1QGqIwu X-Proofpoint-ORIG-GUID: tiopqK5P89Y2UO3itv4K-Kxhl1QGqIwu X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-03-16_09,2023-03-16_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxscore=0 bulkscore=0 mlxlogscore=440 impostorscore=0 lowpriorityscore=0 suspectscore=0 phishscore=0 malwarescore=0 adultscore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303150002 definitions=main-2303160112 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline 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? 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 > > > > > >