Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <20230615193546.949657149@infradead.org>
User-Agent: quilt/0.66
Date:   Thu, 15 Jun 2023 21:35:46 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     x86@kernel.org, alyssa.milburn@linux.intel.com
Cc:     linux-kernel@vger.kernel.org, peterz@infradead.org,
        samitolvanen@google.com, keescook@chromium.org,
        jpoimboe@kernel.org, joao@overdrivepizza.com,
        tim.c.chen@linux.intel.com
Subject: [PATCH 0/2] x86/cfi: Fix FineIBT
Precedence: bulk

Hi!

Alyssa reported a FineIBT issue; these patches sort that.

Basically the morale of the story is that CALL_NOSPEC and JMP_NOSPEC are
suspect and likely not what you want. The remaining users are:

arch/x86/crypto/crc32c-pcl-intel-asm_64.S:	JMP_NOSPEC bufp

This is broken on anything IBT afaict.

arch/x86/include/asm/mshyperv.h:			     CALL_NOSPEC
arch/x86/include/asm/mshyperv.h:	__asm__ __volatile__(CALL_NOSPEC
arch/x86/include/asm/mshyperv.h:		__asm__ __volatile__(CALL_NOSPEC
arch/x86/include/asm/mshyperv.h:		__asm__ __volatile__ (CALL_NOSPEC
arch/x86/include/asm/mshyperv.h:				     CALL_NOSPEC
arch/x86/include/asm/mshyperv.h:		__asm__ __volatile__ (CALL_NOSPEC
arch/x86/include/asm/xen/hypercall.h:	asm volatile(CALL_NOSPEC

These are hypercalls and supposedly the targets are having ENDBR on.

arch/x86/kernel/ftrace_64.S:	CALL_NOSPEC r8

The thing is !DYNAMIC_FTRACE only, which we can fix with a Kconfig
dependency I suppose.

arch/x86/kvm/emulate.c:	asm("push %[flags]; popf; " CALL_NOSPEC
arch/x86/kvm/emulate.c:	asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n"

calls into the magic fastop stuff and should be ok, those have explicit
ENDBR + IBT_NOSEAL() annotations.

arch/x86/kvm/vmx/vmenter.S:	VMX_DO_EVENT_IRQOFF CALL_NOSPEC _ASM_ARG1

calls the IDT vectors manually, so should be ok (gross, but not broken
from this pov).

arch/x86/platform/efi/efi_stub_64.S:	CALL_NOSPEC rdi

effectively a nocfi call, so should be ok.