public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Marvin Häuser" <mhaeuser@posteo.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>
Subject: Re: [edk2-devel] [RFC 13/13] ArmVirtPkg/ArmVirtQemu: Enable hardware enforced W^X memory permissions
Date: Mon, 13 Feb 2023 22:23:24 +0000	[thread overview]
Message-ID: <60CEC058-0002-45E3-AAD7-8D2BB24CFD57@posteo.de> (raw)
In-Reply-To: <CAMj1kXG4f2mpPCsDr6H9GS8mRGBjUHXNbGHnVF0t+4vg+HbARw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]


> On 13. Feb 2023, at 22:59, Ard Biesheuvel <ardb@kernel.org> wrote:
> 
> No, the only reason for adding -fpie here is to ensure that statically
> initialized CONST pointers are emitted into .data.rel.ro and not into
> .rodata, as this is under the control of the compiler. Although,
> thinking about this, I wonder if we need to pass this to the linker
> for codegen under LTO as well. But the PIE link itself should be
> unnecessary here.

Oh, what fun. For some reason I thought it would be unsafe to specify -fpie but not -pie, but considering PIE relocs are ignored either way, this actually makes perfect sense. Sorry! About that last part, the docs say: "It is recommended that you compile all the files participating in the same link with the same options and also specify those options at link time." [1], so good catch!

[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options

But what about -fno-plt?

> 
> It will if you pass -pie to the linker, which is why I would prefer to
> avoid that. The main issue IIRC is that the emit-relocs section does
> not cover the entries in the GOT table that also require relocation,
> and are only covered by the PIE .rela section. For AArch64, I added
> relaxation logic to GenFw to actually patch the instructions instead,
> which is always possible given the absence of dynamic linking.
> (d2687f23c909475d80cef32cdf9a5d121f0a9ae6,
> 7b8f69d7e10628d473dd225224d8c2122d25a38d)

Yes, seen, very nice. I do wonder though why GOT entries are generated in the first place when symbols are all local and data is within the PC-addressable range. Just today, for a X64 build, I actually saw Clang relax a GOT reference to __stack_chk_guard itself.

> 
> This means that we don't have to care about compiler generated symbol
> references, and so the relocs emitted by emit-relocs are sufficient,
> and the additional ones emitted into .rela are unused anyway. The only
> remaining absolute references are the ones resulting from statically
> initialized globals, and those will either be in .data or in
> .data.rel.ro (if -fpie is being used)

Right. thank you.

Best regards,
Marvin

[-- Attachment #2: Type: text/html, Size: 2832 bytes --]

  reply	other threads:[~2023-02-13 22:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13 15:17 [RFC 00/13] Hardware enforced W^X memory protections Ard Biesheuvel
2023-02-13 15:17 ` [RFC 01/13] ArmPkg/Mmu: Remove handling of NONSECURE memory regions Ard Biesheuvel
2023-02-13 15:17 ` [RFC 02/13] ArmPkg/ArmMmuLib: Introduce region types for RO/XP WB cached memory Ard Biesheuvel
2023-02-13 15:18 ` [RFC 03/13] MdePkg/BasePeCoffLib: Add API to keep track of relocation range Ard Biesheuvel
2023-02-13 15:18 ` [RFC 04/13] MdeModulePkg/DxeIpl: Avoid shadowing IPL PEIM by default Ard Biesheuvel
2023-02-13 15:18 ` [RFC 05/13] MdeModulePkg/DxeIpl AARCH64: Remap DXE core code section before launch Ard Biesheuvel
2023-02-13 15:18 ` [RFC 06/13] MdeModulePkg/DxeCore: Reduce range of W+X remaps at EBS time Ard Biesheuvel
2023-02-13 15:18 ` [RFC 07/13] MdeModulePkg/DxeCore: Permit preliminary CPU arch fallback Ard Biesheuvel
2023-02-13 21:32   ` [edk2-devel] " Marvin Häuser
2023-02-13 22:07     ` Ard Biesheuvel
2023-02-13 22:24       ` Marvin Häuser
2023-02-13 15:18 ` [RFC 08/13] ArmPkg: Implement ArmSetMemoryOverrideLib Ard Biesheuvel
2023-02-13 15:18 ` [RFC 09/13] ArmVirtPkg/ArmVirtQemu: Use XP memory mappings by default Ard Biesheuvel
2023-02-13 15:18 ` [RFC 10/13] ArmVirtPkg/ArmVirtQemu: Use PEI flavor of ArmMmuLib for all PEIMs Ard Biesheuvel
2023-02-13 15:18 ` [RFC 11/13] ArmVirtPkg/ArmVirtQemu: Use read-only memory region type for code flash Ard Biesheuvel
2023-02-13 15:18 ` [RFC 12/13] BaseTools/GccBase AARCH64: Avoid page sharing between code and data Ard Biesheuvel
2023-02-13 15:18 ` [RFC 13/13] ArmVirtPkg/ArmVirtQemu: Enable hardware enforced W^X memory permissions Ard Biesheuvel
2023-02-13 21:16   ` [edk2-devel] " Marvin Häuser
2023-02-13 21:59     ` Ard Biesheuvel
2023-02-13 22:23       ` Marvin Häuser [this message]
2023-02-13 22:37         ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=60CEC058-0002-45E3-AAD7-8D2BB24CFD57@posteo.de \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox