[0/8] arm64: ARMv8.5-A: Branch Target Identification support

Message

Dave Martin May 24, 2019, 10:25 a.m. UTC

This patch implements support for ARMv8.5-A Branch Target Identification
(BTI), which is a control flow integrity protection feature introduced
as part of the ARMv8.5-A extensions [1].

The series is based on v5.2-rc1.

Patch 1 is from Yu-Cheng Yu of Intel, providing generic support
for parsing the ELF NT_GNU_PROPERTY_TYPE_0 note.  It makes sense to
share this mechanism with x86 rather than reinventing it.


Various things need nailing down before this can be upstreamable:

 * Not tested with hugepages yet.  (If anyone has any suggestions about
   how best to do that, please shout!)

 * The NT_GNU_PROPERTY_TYPE_0 ELF note parsing support is not upstream
   yet and may be subject to further change.

Todo:

 * Add BTI protection in the vDSO, so that user code can no longer
   jump to random locations in there.  Lack of this protection doesn't
   break anything, however.


Tested on the ARM Fast Model.

Notes:

 * GCC 9 can compile backwards-compatible BTI-enabled code with
   -mbranch-protection=bti or -mbranch-protection=standard.

 * Binutils trunk supports the new ELF note, but this isn't in a release
   yet.

   Creation of a BTI-enabled binary requires _everything_ linked in to
   be BTI-enabled.  For now ld --force-bti can be used to override this,
   but some things may break until the required C library support is in
   place.

   There is no straightforward way to mark a .s file as BTI-enabled:
   scraping the output from gcc -S works as a quick hack for now.

   readelf -n can be used to examing the program properties in an ELF
   file.

 * Runtime mmap() and mprotect() can be used to enable BTI on a
   page-by-page basis using the new PROT_BTI_GUARDED, but the code in
   the affected pages still needs to be written or compiled to contain
   the appopriate BTI landing pads.


Dave Martin (7):
  mm: Reserve asm-generic prot flag 0x10 for arch use
  arm64: docs: cpu-feature-registers: Document ID_AA64PFR1_EL1
  arm64: Basic Branch Target Identification support
  elf: Parse program properties before destroying the old process
  elf: Allow arch to tweak initial mmap prot flags
  arm64: elf: Enable BTI at exec based on ELF program properties
  arm64: BTI: Decode BYTPE bits when printing PSTATE

Yu-cheng Yu (1):
  binfmt_elf: Extract .note.gnu.property from an ELF file

 Documentation/arm64/cpu-feature-registers.txt |  18 +-
 Documentation/arm64/elf_hwcaps.txt            |   4 +
 arch/arm64/Kconfig                            |  26 ++
 arch/arm64/include/asm/cpucaps.h              |   3 +-
 arch/arm64/include/asm/cpufeature.h           |   6 +
 arch/arm64/include/asm/elf.h                  |  28 ++
 arch/arm64/include/asm/esr.h                  |   2 +-
 arch/arm64/include/asm/hwcap.h                |   1 +
 arch/arm64/include/asm/mman.h                 |  33 +++
 arch/arm64/include/asm/pgtable-hwdef.h        |   1 +
 arch/arm64/include/asm/pgtable.h              |   2 +-
 arch/arm64/include/asm/ptrace.h               |   3 +
 arch/arm64/include/asm/sysreg.h               |   2 +
 arch/arm64/include/uapi/asm/hwcap.h           |   1 +
 arch/arm64/include/uapi/asm/mman.h            |   9 +
 arch/arm64/include/uapi/asm/ptrace.h          |   1 +
 arch/arm64/kernel/cpufeature.c                |  17 ++
 arch/arm64/kernel/cpuinfo.c                   |   1 +
 arch/arm64/kernel/entry.S                     |  11 +
 arch/arm64/kernel/process.c                   |  64 ++++-
 arch/arm64/kernel/ptrace.c                    |   2 +-
 arch/arm64/kernel/signal.c                    |   5 +
 arch/arm64/kernel/syscall.c                   |   1 +
 arch/arm64/kernel/traps.c                     |   7 +
 fs/Kconfig.binfmt                             |   7 +
 fs/Makefile                                   |   1 +
 fs/binfmt_elf.c                               |  31 ++-
 fs/gnu_property.c                             | 363 ++++++++++++++++++++++++++
 include/linux/elf.h                           |  32 +++
 include/linux/mm.h                            |   3 +
 include/uapi/asm-generic/mman-common.h        |   1 +
 include/uapi/linux/elf.h                      |  14 +
 32 files changed, 684 insertions(+), 16 deletions(-)
 create mode 100644 arch/arm64/include/asm/mman.h
 create mode 100644 arch/arm64/include/uapi/asm/mman.h
 create mode 100644 fs/gnu_property.c

Comments

Richard Henderson June 5, 2019, 9:12 p.m. UTC | #1

On 5/24/19 5:25 AM, Dave Martin wrote:
> Various things need nailing down before this can be upstreamable:
> 
>  * Not tested with hugepages yet.  (If anyone has any suggestions about
>    how best to do that, please shout!)

The qemu code_gen_buffer is generally between 32MB and 2GB, contiguous.  It
usually gets AnonHugePage'd.  I assume there's no difference in where the
hugepages come from on your side?

It won't be too difficult to modify qemu to make it's own code generation
BTI-safe, and is on the schedule to do eventually anyway.


r~

Dave Martin June 6, 2019, 9:34 a.m. UTC | #2

On Wed, Jun 05, 2019 at 04:12:03PM -0500, Richard Henderson wrote:
> On 5/24/19 5:25 AM, Dave Martin wrote:
> > Various things need nailing down before this can be upstreamable:
> > 
> >  * Not tested with hugepages yet.  (If anyone has any suggestions about
> >    how best to do that, please shout!)
> 
> The qemu code_gen_buffer is generally between 32MB and 2GB, contiguous.  It
> usually gets AnonHugePage'd.  I assume there's no difference in where the
> hugepages come from on your side?

There are some internal differences between hugetlbfs and anonymous huge
pages, but I'm not very familiar with the details.

> It won't be too difficult to modify qemu to make it's own code generation
> BTI-safe, and is on the schedule to do eventually anyway.

For userspace, it really shouldn't make a difference where the pages
come from.  With hugetlbfs, probably mprotect() only works at huge page
granularity; for anonymous huge pages, mprotect() should work at page
granularity, with the kernel shattering huge pages as required.

I guess I can come up with a handcrafted test or two.

Cheers
---Dave