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.9510.1675428972618208584 for ; Fri, 03 Feb 2023 04:56:12 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=fUI99ZFU; 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 1DFC061F2F for ; Fri, 3 Feb 2023 12:56:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDCF2C433A1 for ; Fri, 3 Feb 2023 12:56:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675428971; bh=wvL4qM2BfVT6Gk4bPBIJxoEERCBcHtAQTq8d5QuB4zM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fUI99ZFUX+nMgV+tBgm4piS+AkGE77grIraQT5e53BVsizbtdEacnQIBSvgl6WF7w 19EIbSH7sG7zZlfsjDPra/YfHoSHYBjfZjMOZvcyQgImmETEwfuraYChi49VZFsfbg BkwECDQjz4ooa1UeNTDXvfhvSMWNDdecnCQ2psu3lFT4cHAlE1Nm7ue0gh1Woua+n/ zY34wIY8ZQGWk69iZHT3Gx4LK/AlfhuJdDdXpKRbelrksuwCUxhoISlGQfzKQB4Kxd XixSLUcKdzuZHIkRMfgDVCj7+T2ahDIw5vhMxaWUVT7HiuSR0/toA8wqjLoxcYIl7M S3GB1xdGVQZag== Received: by mail-lj1-f171.google.com with SMTP id u27so5113800ljo.12 for ; Fri, 03 Feb 2023 04:56:10 -0800 (PST) X-Gm-Message-State: AO0yUKXfTq0l6XswRSzXENAXCfHQFnmaVuEWPX+jAk3qdCXPYuYyRACL JhgBNhuwHaq+ZNcWPKfljTgIgKjGAFW+PtkWLuw= X-Google-Smtp-Source: AK7set+KqjAO5irny9O1AgjIZtd9yOpMcmuqrKPRylYMasjIgYyO0IAw5E2sRfb9g2EZbCeiKRDEdgtZWhEmXXHvW6o= X-Received: by 2002:a2e:a609:0:b0:290:5011:2332 with SMTP id v9-20020a2ea609000000b0029050112332mr1307361ljp.120.1675428968877; Fri, 03 Feb 2023 04:56:08 -0800 (PST) MIME-Version: 1.0 References: <20230203121029.2451394-1-ardb@kernel.org> <20230203121029.2451394-8-ardb@kernel.org> <0102018617449762-c2f2f6c3-1532-41d5-ae76-d7c63ee61d49-000000@eu-west-1.amazonses.com> In-Reply-To: <0102018617449762-c2f2f6c3-1532-41d5-ae76-d7c63ee61d49-000000@eu-west-1.amazonses.com> From: "Ard Biesheuvel" Date: Fri, 3 Feb 2023 13:55:57 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [RFC PATCH v2 7/7] ArmVirtPkg: Implement BTI for runtime regions To: Michael Brown Cc: devel@edk2.groups.io, Michael Kinney , Liming Gao , Jiewen Yao , Michael Kubacki , Sean Brogan , Rebecca Cran , Leif Lindholm , Sami Mujawar , Taylor Beebe , =?UTF-8?Q?Marvin_H=C3=A4user?= Content-Type: text/plain; charset="UTF-8" On Fri, 3 Feb 2023 at 13:33, Michael Brown wrote: > > On 03/02/2023 12:10, Ard Biesheuvel wrote: > > +[BuildOptions] > > +!if $(RUNTIME_BTI_ENABLE) == TRUE > > + GCC:*_*_AARCH64_CC_FLAGS = -mbranch-protection=bti > > +!endif > > Question: as a producer of externally loaded UEFI binaries (e.g. > ipxe.efi): what would I need to do to take advantage of BTI? > > I'm assuming: > > - enable -mbranch-protection=bti in my builds (easy) > > - wait for PE/COFF specification change and then update my produced > images to include whatever flag gets decided upon. > > Is that correct? > First of all, in case you missed this, the series in question only covers runtime DXE drivers, i.e., the code that persists after ExitBootServices() and gets mapped by the OS and called to access the variable store. So iPXE should not be affected at all by these changes. So building your code with branch protection enabled is not going to have any benefit until we decide how to deploy this at boot time, and I think the conclusion on this thread is already that the only meaningful way to do this is to introduce a PE/COFF image flag that indicates whether or not a certain image was built with indirect branch protection. I could also imagine that, at boot time, it would be feasible to apply these protections at image granularity, rather than as a global switch, given that (at least on ARM) these mitigations can be enabled on a per-page basis, and there is no need to turn it off completely when, say, the GOP driver on the video card does not support it. I am not aware of any discussion around this, though - I hope we can get the right folks at MS involved to drive the PE/COFF side of this and then, I am more than happy to take (joint) ownership of this on the Tianocore side, and hammer something out that works for everyone. Jiewen, Mike; could you comment on the IBT side? Does x86 permit IBT enforcement on a per-page basis as well? Could we feasibly add this to the code/data rx/rw remapping code, to enable indirect branch protection as each image is loaded by the DXE core? So to answer your question: yes.