mbox series

[v2,00/10] arm64: BTI kernel and vDSO support

Message ID 20200429211641.9279-1-broonie@kernel.org (mailing list archive)
Headers show
Series arm64: BTI kernel and vDSO support | expand

Message

Mark Brown April 29, 2020, 9:16 p.m. UTC
This patch series adds support for protecting the kernel and vDSO with
BTI including code compiled with the BPF JIT at runtime.

We build the kernel with annotations for BTI and then map the kernel
with GP based on the support on the boot CPU, rejecting secondaries that
don't have BTI support. If there is a need to handle big.LITTLE systems
with mismatched BTI support we will have to revisit this, currently no
such implementations exist.

I'm currently finalizing testing of the BPF support, the in-kernel
test_bpf tests run cleanly.

This series depends on:

 - for-next/bti in the arm64 tree
 - The series "arm64: Finish up assembler annotation modernisation"
 - The series "arm64: Make NOP handling a whitelist"

There is some discussion between Catalin and Will about the use of a
separate Kconfig option for this, I've left the separate option for now.

v2:
 - Enable support for building with GCC version 10 and later, a fix
   for BTI code generation is being backported to GCC 9 but is not yet
   available.
 - Add BPF support.
 - Remove some unused page attribute defines.
 - One assembler modernisation patch has been removed and sent
   separately.

Mark Brown (10):
  arm64: bti: Support building kernel C code using BTI
  arm64: asm: Override SYM_FUNC_START when building the kernel with BTI
  arm64: Set GP bit in kernel page tables to enable BTI for the kernel
  arm64: bpf: Annotate JITed code for BTI
  arm64: mm: Mark executable text as guarded pages
  arm64: bti: Provide Kconfig for kernel mode BTI
  arm64: asm: Provide a mechanism for generating ELF note for BTI
  arm64: vdso: Annotate for BTI
  arm64: vdso: Force the vDSO to be linked as BTI when built for BTI
  arm64: vdso: Map the vDSO text with guarded pages when built for BTI

 arch/arm64/Kconfig                    | 18 +++++++++++
 arch/arm64/Makefile                   |  4 +++
 arch/arm64/include/asm/assembler.h    | 41 ++++++++++++++++++++++++
 arch/arm64/include/asm/linkage.h      | 46 +++++++++++++++++++++++++++
 arch/arm64/include/asm/pgtable-prot.h |  3 ++
 arch/arm64/kernel/cpufeature.c        |  4 +++
 arch/arm64/kernel/vdso.c              |  6 +++-
 arch/arm64/kernel/vdso/Makefile       |  4 ++-
 arch/arm64/kernel/vdso/note.S         |  3 ++
 arch/arm64/kernel/vdso/sigreturn.S    |  3 ++
 arch/arm64/kernel/vdso/vdso.S         |  3 ++
 arch/arm64/mm/mmu.c                   | 24 ++++++++++++++
 arch/arm64/mm/pageattr.c              |  4 +--
 arch/arm64/net/bpf_jit.h              |  8 +++++
 arch/arm64/net/bpf_jit_comp.c         | 12 +++++++
 15 files changed, 179 insertions(+), 4 deletions(-)

Comments

Catalin Marinas April 30, 2020, 5:18 p.m. UTC | #1
On Wed, Apr 29, 2020 at 10:16:31PM +0100, Mark Brown wrote:
> We build the kernel with annotations for BTI and then map the kernel
> with GP based on the support on the boot CPU, rejecting secondaries that
> don't have BTI support. If there is a need to handle big.LITTLE systems
> with mismatched BTI support we will have to revisit this, currently no
> such implementations exist.

It's fine by me to live with this assumption.

> I'm currently finalizing testing of the BPF support, the in-kernel
> test_bpf tests run cleanly.
> 
> This series depends on:
> 
>  - for-next/bti in the arm64 tree
>  - The series "arm64: Finish up assembler annotation modernisation"
>  - The series "arm64: Make NOP handling a whitelist"
> 
> There is some discussion between Catalin and Will about the use of a
> separate Kconfig option for this, I've left the separate option for now.

Leave them separated, we may do the same for PAC.

We could allow the vdso to use BTI while the kernel option is disabled
but I don't think it's worth the hassle.

> v2:
>  - Enable support for building with GCC version 10 and later, a fix
>    for BTI code generation is being backported to GCC 9 but is not yet
>    available.

Do you have a link to a GCC commit or bugzilla? (for future reference,
no need to update the patch).

The series looks fine to me.

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Mark Brown April 30, 2020, 5:23 p.m. UTC | #2
On Thu, Apr 30, 2020 at 06:18:43PM +0100, Catalin Marinas wrote:
> On Wed, Apr 29, 2020 at 10:16:31PM +0100, Mark Brown wrote:

> > v2:
> >  - Enable support for building with GCC version 10 and later, a fix
> >    for BTI code generation is being backported to GCC 9 but is not yet
> >    available.

> Do you have a link to a GCC commit or bugzilla? (for future reference,
> no need to update the patch).

I found these:

	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
	https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544429.html

> The series looks fine to me.

> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

Thanks.