This seems like a tricky extension to deploy to the operating system.
What is the proposed interface for setting GP on application pages? There are several things that seem plausible to me, and I wondered how far planning has gotten.
An mmap/mprotect flag?
An ELF program header PT_ARM_BTI (a-la PT_GNU_RELRO) to direct the loader to set said flag when mapping binaries? Or equivalently, a PF_MASKOS bit that could be set on the normal PT_LOAD header.
An ELF section flag set by the compiler for sections that use -mbti, which are then collected into the PT_GNU_BTI segment by the linker?
That seems like the most plausible way to indicate on a per-binary basis that it has been compiled with the BTI hints in place. But probably there are other ways that make an equal amount of sense.
Is there any coordination going on with Intel wrt their similar gadget protection scheme(s)?
r~
Hi Richard,
[expanding CC to include others who may be interested in this]
On Fri, Dec 14, 2018 at 04:57:02PM -0600, Richard Henderson wrote:
This seems like a tricky extension to deploy to the operating system.
What is the proposed interface for setting GP on application pages? There are several things that seem plausible to me, and I wondered how far planning has gotten.
I've not seen anything set in stone yet, so I think this is all still up for grabs. Ramana?
An mmap/mprotect flag?
I'm not aware of any precedent for arch-specific mmap/mprotect flags, but it looks like PowerPC adds its own PROT bit for "Strong Access Ordering" so something similar might be do-able for GP on arm64.
However, if we anticipate that pages are either GP or !GP for the lifetime of the mapping, I think your suggestions below relating to encoding this in the ELF make more sense.
An ELF program header PT_ARM_BTI (a-la PT_GNU_RELRO) to direct the loader to set said flag when mapping binaries? Or equivalently, a PF_MASKOS bit that could be set on the normal PT_LOAD header.
An ELF section flag set by the compiler for sections that use -mbti, which are then collected into the PT_GNU_BTI segment by the linker?
That seems like the most plausible way to indicate on a per-binary basis that it has been compiled with the BTI hints in place. But probably there are other ways that make an equal amount of sense.
Is there any coordination going on with Intel wrt their similar gadget protection scheme(s)?
I'm not familiar with that. Are there patches out for review?
Will
On 1/8/19 9:25 PM, Will Deacon wrote:
An mmap/mprotect flag?
I'm not aware of any precedent for arch-specific mmap/mprotect flags, but it looks like PowerPC adds its own PROT bit for "Strong Access Ordering" so something similar might be do-able for GP on arm64.
However, if we anticipate that pages are either GP or !GP for the lifetime of the mapping, I think your suggestions below relating to encoding this in the ELF make more sense.
Even if the main usage is via ELF, you need the flag for ld.so to use when mmap'ing the file.
r~
On Tue, Jan 08, 2019 at 11:25:08AM +0000, Will Deacon wrote:
Hi Richard,
[expanding CC to include others who may be interested in this]
On Fri, Dec 14, 2018 at 04:57:02PM -0600, Richard Henderson wrote:
This seems like a tricky extension to deploy to the operating system.
What is the proposed interface for setting GP on application pages? There are several things that seem plausible to me, and I wondered how far planning has gotten.
I've not seen anything set in stone yet, so I think this is all still up for grabs. Ramana?
An mmap/mprotect flag?
I'm not aware of any precedent for arch-specific mmap/mprotect flags, but it looks like PowerPC adds its own PROT bit for "Strong Access Ordering" so something similar might be do-able for GP on arm64.
However, if we anticipate that pages are either GP or !GP for the lifetime of the mapping, I think your suggestions below relating to encoding this in the ELF make more sense.
IIUC, the plan today is to have both:
* An ELF note so that the kernel can set BTI on text pages in the initial ELF image, if that ELF was built with BTI.
* A PROT_BIT so that mmap() and friends can enable BTI on pages dynamically. That's necessary for JITs and ld.so.
Ramana or Dave should be able to elaborate on the finer details.
Thanks, Mark.
On Tue, Jan 08, 2019 at 11:25:08AM +0000, Will Deacon wrote:
Hi Richard,
[expanding CC to include others who may be interested in this]
On Fri, Dec 14, 2018 at 04:57:02PM -0600, Richard Henderson wrote:
This seems like a tricky extension to deploy to the operating system.
What is the proposed interface for setting GP on application pages? There are several things that seem plausible to me, and I wondered how far planning has gotten.
I've not seen anything set in stone yet, so I think this is all still up for grabs. Ramana?
I had some patches in the pipeline, though I'm not ready to post anything quite yet... I'm open to suggestions though!
An mmap/mprotect flag?
I'm not aware of any precedent for arch-specific mmap/mprotect flags, but it looks like PowerPC adds its own PROT bit for "Strong Access Ordering" so something similar might be do-able for GP on arm64.
There are a few others too, like sparc's PROT_ADI.
So, a precedent has been set (though for portability reasons, arch- specific prot flags shouldn't be added without good reason).
However, if we anticipate that pages are either GP or !GP for the lifetime of the mapping, I think your suggestions below relating to encoding this in the ELF make more sense.
For pages that are mapped from the ELF image, yes. A prot flag is still needed for runtime-allocated pages though -- for example, a BTI-aware JIT will want to set this flag on the code it generates. So there is probably is sufficient reason to add such a flag.
An ELF program header PT_ARM_BTI (a-la PT_GNU_RELRO) to direct the loader to set said flag when mapping binaries? Or equivalently, a PF_MASKOS bit that could be set on the normal PT_LOAD header.
This has the advantage of simplicity, but I have heard the objection raised by toolchain guys that these bits are considered a scarce resource and it's not clear whether it's worth burning a bit on this.
It's currently a bit doubtful whether there is any legitimate reason to mix BTI and non-BTI code generation in the same compilation unit, so it may be sufficient to mark BTI-ness at whole-ELF granularity, possibly a scheme such as this Intel proposal [3] which is proposed for use somehow to mark ELF images for branch tracking on x86 (see [2]; I haven't dug into it much myself).
Assuming we do something similar for BTI, this would mean that statically linked binaries don't get BTI enabled unless all the constituent libraries are built for BTI, which may or may not be a concern.
An ELF section flag set by the compiler for sections that use -mbti, which are then collected into the PT_GNU_BTI segment by the linker?
This is possible, but may be a bit invasive on the toolchain side.
Again, it's unclear whether it's really useful (or desirable) for individual ELF images to contain mixed BTI/non-BTI code.
That seems like the most plausible way to indicate on a per-binary basis that it has been compiled with the BTI hints in place. But probably there are other ways that make an equal amount of sense.
Is there any coordination going on with Intel wrt their similar gadget protection scheme(s)?
I'm not familiar with that. Are there patches out for review?
There are some patches out there [1] [2], but there is not a direct parallel with BTI since the architectural approach is somewhat different. I'm not aware of a new page flag for this.
Cheers ---Dave
[1] [RFC PATCH v6 00/26] Control-flow Enforcement: Shadow Stack https://lore.kernel.org/lkml/20181119214809.6086-1-yu-cheng.yu@intel.com/
[2] [RFC PATCH v6 00/11] Control-flow Enforcement: Branch Tracking, PTRACE https://lore.kernel.org/lkml/20181119214934.6174-1-yu-cheng.yu@intel.com/
[3] https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf
linaro-toolchain@lists.linaro.org
-
Dave Martin -
Mark Rutland -
Richard Henderson -
Will Deacon