[PATCH v22 0/8] Control-flow Enforcement: Indirect Branch Tracking

[PATCH v22 0/8] Control-flow Enforcement: Indirect Branch Tracking

[Yu-cheng Yu]

Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks.  Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].

This is the second part of CET and enables Indirect Branch Tracking (IBT).
It is built on top of the shadow stack series.

Changes in v22:
- Add patch #8: Add endbr64 to sgx vdso entry point.
- Rebase to Linus tree v5.12-rc2.

[1] Intel 64 and IA-32 Architectures Software Developer's Manual:

    https://software.intel.com/en-us/download/intel-64-and-ia-32-
    architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4

[2] Indirect Branch Tracking patches v21:

    https://lore.kernel.org/r/20210217223135.16790-1-yu-cheng.yu@intel.com/

H.J. Lu (3):
  x86/cet/ibt: Update arch_prctl functions for Indirect Branch Tracking
  x86/vdso/32: Add ENDBR32 to __kernel_vsyscall entry point
  x86/vdso: Insert endbr32/endbr64 to vDSO

Yu-cheng Yu (5):
  x86/cet/ibt: Update Kconfig for user-mode Indirect Branch Tracking
  x86/cet/ibt: User-mode Indirect Branch Tracking support
  x86/cet/ibt: Handle signals for Indirect Branch Tracking
  x86/cet/ibt: Update ELF header parsing for Indirect Branch Tracking
  x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

 arch/x86/Kconfig                         |  1 +
 arch/x86/entry/vdso/Makefile             |  4 ++
 arch/x86/entry/vdso/vdso32/system_call.S |  3 ++
 arch/x86/entry/vdso/vsgx.S               |  3 ++
 arch/x86/include/asm/cet.h               |  3 ++
 arch/x86/kernel/cet.c                    | 59 +++++++++++++++++++++++-
 arch/x86/kernel/cet_prctl.c              |  5 ++
 arch/x86/kernel/fpu/signal.c             |  8 ++--
 arch/x86/kernel/process_64.c             |  8 ++++
 9 files changed, 89 insertions(+), 5 deletions(-)

-- 
2.21.0

[PATCH v22 1/8] x86/cet/ibt: Update Kconfig for user-mode Indirect Branch Tracking

[Yu-cheng Yu]

Indirect branch tracking is a hardware security feature that verifies near
indirect call/jump instructions arrive at intended targets, which are
labeled by the compiler with ENDBR opcodes.  If such instructions reach
unlabeled locations, the processor raises control-protection faults.

Check the compiler is up-to-date at config time.

Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2c93178262f5..96000ed48469 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1953,6 +1953,7 @@ config X86_CET
 	def_bool n
 	depends on AS_WRUSS
 	depends on ARCH_HAS_SHADOW_STACK
+	depends on $(cc-option,-fcf-protection)
 	select ARCH_USES_HIGH_VMA_FLAGS
 	select ARCH_MAYBE_MKWRITE
 	select ARCH_USE_GNU_PROPERTY
-- 
2.21.0

[PATCH v22 2/8] x86/cet/ibt: User-mode Indirect Branch Tracking support

[Yu-cheng Yu]

Introduce user-mode Indirect Branch Tracking (IBT) support.  Add routines
for the setup/disable of IBT.

Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/include/asm/cet.h |  3 +++
 arch/x86/kernel/cet.c      | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 36 insertions(+)

diff --git a/arch/x86/include/asm/cet.h b/arch/x86/include/asm/cet.h
index c2437378f339..c20c2f671145 100644
--- a/arch/x86/include/asm/cet.h
+++ b/arch/x86/include/asm/cet.h
@@ -15,6 +15,7 @@ struct cet_status {
 	unsigned long	shstk_base;
 	unsigned long	shstk_size;
 	unsigned int	locked:1;
+	unsigned int	ibt_enabled:1;
 };
 
 #ifdef CONFIG_X86_CET
@@ -27,6 +28,8 @@ void cet_free_shstk(struct task_struct *p);
 int cet_verify_rstor_token(bool ia32, unsigned long ssp, unsigned long *new_ssp);
 void cet_restore_signal(struct sc_ext *sc);
 int cet_setup_signal(bool ia32, unsigned long rstor, struct sc_ext *sc);
+int cet_setup_ibt(void);
+void cet_disable_ibt(void);
 #else
 static inline int prctl_cet(int option, u64 arg2) { return -EINVAL; }
 static inline int cet_setup_thread_shstk(struct task_struct *p,
diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c
index 12738cdfb5f2..3361706ba950 100644
--- a/arch/x86/kernel/cet.c
+++ b/arch/x86/kernel/cet.c
@@ -13,6 +13,8 @@
 #include <linux/uaccess.h>
 #include <linux/sched/signal.h>
 #include <linux/compat.h>
+#include <linux/vmalloc.h>
+#include <linux/bitops.h>
 #include <asm/msr.h>
 #include <asm/user.h>
 #include <asm/fpu/internal.h>
@@ -346,3 +348,34 @@ int cet_setup_signal(bool ia32, unsigned long rstor_addr, struct sc_ext *sc_ext)
 
 	return 0;
 }
+
+int cet_setup_ibt(void)
+{
+	u64 msr_val;
+
+	if (!static_cpu_has(X86_FEATURE_IBT))
+		return -EOPNOTSUPP;
+
+	start_update_msrs();
+	rdmsrl(MSR_IA32_U_CET, msr_val);
+	msr_val |= (CET_ENDBR_EN | CET_NO_TRACK_EN);
+	wrmsrl(MSR_IA32_U_CET, msr_val);
+	end_update_msrs();
+	current->thread.cet.ibt_enabled = 1;
+	return 0;
+}
+
+void cet_disable_ibt(void)
+{
+	u64 msr_val;
+
+	if (!static_cpu_has(X86_FEATURE_IBT))
+		return;
+
+	start_update_msrs();
+	rdmsrl(MSR_IA32_U_CET, msr_val);
+	msr_val &= ~CET_ENDBR_EN;
+	wrmsrl(MSR_IA32_U_CET, msr_val);
+	end_update_msrs();
+	current->thread.cet.ibt_enabled = 0;
+}
-- 
2.21.0

[PATCH v22 3/8] x86/cet/ibt: Handle signals for Indirect Branch Tracking

[Yu-cheng Yu]

When an indirect CALL/JMP instruction is executed and before it reaches
the target, it is in 'WAIT_ENDBR' status, which can be read from
MSR_IA32_U_CET.  The status is part of a task's status before a signal is
raised and preserved in the signal frame.  It is restored for sigreturn.

IBT state machine is described in Intel SDM Vol. 1, Sec. 18.3.

Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/kernel/cet.c        | 26 ++++++++++++++++++++++++--
 arch/x86/kernel/fpu/signal.c |  8 +++++---
 2 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c
index 3361706ba950..34a26eb7f259 100644
--- a/arch/x86/kernel/cet.c
+++ b/arch/x86/kernel/cet.c
@@ -300,6 +300,13 @@ void cet_restore_signal(struct sc_ext *sc_ext)
 		msr_val |= CET_SHSTK_EN;
 	}
 
+	if (cet->ibt_enabled) {
+		msr_val |= (CET_ENDBR_EN | CET_NO_TRACK_EN);
+
+		if (sc_ext->wait_endbr)
+			msr_val |= CET_WAIT_ENDBR;
+	}
+
 	if (test_thread_flag(TIF_NEED_FPU_LOAD))
 		cet_user_state->user_cet = msr_val;
 	else
@@ -340,9 +347,24 @@ int cet_setup_signal(bool ia32, unsigned long rstor_addr, struct sc_ext *sc_ext)
 		sc_ext->ssp = new_ssp;
 	}
 
-	if (ssp) {
+	if (ssp || cet->ibt_enabled) {
 		start_update_msrs();
-		wrmsrl(MSR_IA32_PL3_SSP, ssp);
+
+		if (ssp)
+			wrmsrl(MSR_IA32_PL3_SSP, ssp);
+
+		if (cet->ibt_enabled) {
+			u64 r;
+
+			rdmsrl(MSR_IA32_U_CET, r);
+
+			if (r & CET_WAIT_ENDBR) {
+				sc_ext->wait_endbr = 1;
+				r &= ~CET_WAIT_ENDBR;
+				wrmsrl(MSR_IA32_U_CET, r);
+			}
+		}
+
 		end_update_msrs();
 	}
 
diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
index 270e4649f435..b914d74c8ba6 100644
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -57,7 +57,8 @@ int save_cet_to_sigframe(int ia32, void __user *fp, unsigned long restorer)
 {
 	int err = 0;
 
-	if (!current->thread.cet.shstk_size)
+	if (!current->thread.cet.shstk_size &&
+	    !current->thread.cet.ibt_enabled)
 		return 0;
 
 	if (fp) {
@@ -89,7 +90,8 @@ static int get_cet_from_sigframe(int ia32, void __user *fp, struct sc_ext *ext)
 
 	memset(ext, 0, sizeof(*ext));
 
-	if (!current->thread.cet.shstk_size)
+	if (!current->thread.cet.shstk_size &&
+	    !current->thread.cet.ibt_enabled)
 		return 0;
 
 	if (fp) {
@@ -577,7 +579,7 @@ static unsigned long fpu__alloc_sigcontext_ext(unsigned long sp)
 	 * sigcontext_ext is at: fpu + fpu_user_xstate_size +
 	 * FP_XSTATE_MAGIC2_SIZE, then aligned to 8.
 	 */
-	if (cet->shstk_size)
+	if (cet->shstk_size || cet->ibt_enabled)
 		sp -= (sizeof(struct sc_ext) + 8);
 
 	return sp;
-- 
2.21.0

[PATCH v22 4/8] x86/cet/ibt: Update ELF header parsing for Indirect Branch Tracking

[Yu-cheng Yu]

An ELF file's .note.gnu.property indicates features the file supports.
The property is parsed at loading time and passed to arch_setup_elf_
property().  Update it for Indirect Branch Tracking.

Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/kernel/process_64.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index cda830b0f7ee..11497689a841 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -864,6 +864,14 @@ int arch_setup_elf_property(struct arch_elf_state *state)
 			r = cet_setup_shstk();
 	}
 
+	if (r < 0)
+		return r;
+
+	if (static_cpu_has(X86_FEATURE_IBT)) {
+		if (state->gnu_property & GNU_PROPERTY_X86_FEATURE_1_IBT)
+			r = cet_setup_ibt();
+	}
+
 	return r;
 }
 #endif
-- 
2.21.0

[PATCH v22 5/8] x86/cet/ibt: Update arch_prctl functions for Indirect Branch Tracking

[Yu-cheng Yu]

From: "H.J. Lu" <hjl.tools@gmail.com>

Update ARCH_X86_CET_STATUS and ARCH_X86_CET_DISABLE for Indirect Branch
Tracking.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/kernel/cet_prctl.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/cet_prctl.c b/arch/x86/kernel/cet_prctl.c
index 0030c63a08c0..4df1eac41965 100644
--- a/arch/x86/kernel/cet_prctl.c
+++ b/arch/x86/kernel/cet_prctl.c
@@ -22,6 +22,9 @@ static int cet_copy_status_to_user(struct cet_status *cet, u64 __user *ubuf)
 		buf[2] = cet->shstk_size;
 	}
 
+	if (cet->ibt_enabled)
+		buf[0] |= GNU_PROPERTY_X86_FEATURE_1_IBT;
+
 	return copy_to_user(ubuf, buf, sizeof(buf));
 }
 
@@ -46,6 +49,8 @@ int prctl_cet(int option, u64 arg2)
 			return -EINVAL;
 		if (arg2 & GNU_PROPERTY_X86_FEATURE_1_SHSTK)
 			cet_disable_shstk();
+		if (arg2 & GNU_PROPERTY_X86_FEATURE_1_IBT)
+			cet_disable_ibt();
 		return 0;
 
 	case ARCH_X86_CET_LOCK:
-- 
2.21.0

[PATCH v22 6/8] x86/vdso/32: Add ENDBR32 to __kernel_vsyscall entry point

[Yu-cheng Yu]

From: "H.J. Lu" <hjl.tools@gmail.com>

Add ENDBR32 to __kernel_vsyscall entry point.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Acked-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/entry/vdso/vdso32/system_call.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/entry/vdso/vdso32/system_call.S b/arch/x86/entry/vdso/vdso32/system_call.S
index de1fff7188aa..f19eaec3de3b 100644
--- a/arch/x86/entry/vdso/vdso32/system_call.S
+++ b/arch/x86/entry/vdso/vdso32/system_call.S
@@ -14,6 +14,9 @@
 	ALIGN
 __kernel_vsyscall:
 	CFI_STARTPROC
+#ifdef CONFIG_X86_CET
+	endbr32
+#endif
 	/*
 	 * Reshuffle regs so that all of any of the entry instructions
 	 * will preserve enough state.
-- 
2.21.0

[PATCH v22 7/8] x86/vdso: Insert endbr32/endbr64 to vDSO

[Yu-cheng Yu]

From: "H.J. Lu" <hjl.tools@gmail.com>

When Indirect Branch Tracking (IBT) is enabled, vDSO functions may be
called indirectly, and must have ENDBR32 or ENDBR64 as the first
instruction.  The compiler must support -fcf-protection=branch so that it
can be used to compile vDSO.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Acked-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/entry/vdso/Makefile | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 05c4abc2fdfd..c9eccbc06e8c 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -93,6 +93,10 @@ endif
 
 $(vobjs): KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_LTO) $(GCC_PLUGINS_CFLAGS) $(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
 
+ifdef CONFIG_X86_CET
+$(vobjs) $(vobjs32): KBUILD_CFLAGS += -fcf-protection=branch
+endif
+
 #
 # vDSO code runs in userspace and -pg doesn't help with profiling anyway.
 #
-- 
2.21.0

[PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Yu-cheng Yu]

When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
in the beginning of the function.

Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
---
 arch/x86/entry/vdso/vsgx.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/entry/vdso/vsgx.S b/arch/x86/entry/vdso/vsgx.S
index 86a0e94f68df..a70d4d09f713 100644
--- a/arch/x86/entry/vdso/vsgx.S
+++ b/arch/x86/entry/vdso/vsgx.S
@@ -27,6 +27,9 @@
 SYM_FUNC_START(__vdso_sgx_enter_enclave)
 	/* Prolog */
 	.cfi_startproc
+#ifdef CONFIG_X86_CET
+	endbr64
+#endif
 	push	%rbp
 	.cfi_adjust_cfa_offset	8
 	.cfi_rel_offset		%rbp, 0
-- 
2.21.0

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Jarkko Sakkinen]

On Wed, Mar 10, 2021 at 02:05:19PM -0800, Yu-cheng Yu wrote:
> When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
> in the beginning of the function.

OK.

What you should do is to explain what it does and why it's needed.

> 
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> ---
>  arch/x86/entry/vdso/vsgx.S | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/entry/vdso/vsgx.S b/arch/x86/entry/vdso/vsgx.S
> index 86a0e94f68df..a70d4d09f713 100644
> --- a/arch/x86/entry/vdso/vsgx.S
> +++ b/arch/x86/entry/vdso/vsgx.S
> @@ -27,6 +27,9 @@
>  SYM_FUNC_START(__vdso_sgx_enter_enclave)
>  	/* Prolog */
>  	.cfi_startproc
> +#ifdef CONFIG_X86_CET
> +	endbr64
> +#endif
>  	push	%rbp
>  	.cfi_adjust_cfa_offset	8
>  	.cfi_rel_offset		%rbp, 0
> -- 
> 2.21.0
> 
> 

/Jarkko

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Yu, Yu-cheng]

On 3/10/2021 2:39 PM, Jarkko Sakkinen wrote:
> On Wed, Mar 10, 2021 at 02:05:19PM -0800, Yu-cheng Yu wrote:
>> When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
>> in the beginning of the function.
> 
> OK.
> 
> What you should do is to explain what it does and why it's needed.
> 

The endbr marks a branch target.  Without the "no-track" prefix, if an 
indirect call/jmp reaches a non-endbr opcode, a control-protection fault 
is raised.  Usually endbr's are inserted by the compiler.  For assembly, 
these have to be put in manually.  I will add this in the commit log if 
there is another revision.  Thanks!

--
Yu-cheng

>>
>> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
>> Cc: Andy Lutomirski <luto@kernel.org>
>> Cc: Dave Hansen <dave.hansen@linux.intel.com>
>> Cc: Jarkko Sakkinen <jarkko@kernel.org>
>> ---
>>   arch/x86/entry/vdso/vsgx.S | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/x86/entry/vdso/vsgx.S b/arch/x86/entry/vdso/vsgx.S
>> index 86a0e94f68df..a70d4d09f713 100644
>> --- a/arch/x86/entry/vdso/vsgx.S
>> +++ b/arch/x86/entry/vdso/vsgx.S
>> @@ -27,6 +27,9 @@
>>   SYM_FUNC_START(__vdso_sgx_enter_enclave)
>>   	/* Prolog */
>>   	.cfi_startproc
>> +#ifdef CONFIG_X86_CET
>> +	endbr64
>> +#endif
>>   	push	%rbp
>>   	.cfi_adjust_cfa_offset	8
>>   	.cfi_rel_offset		%rbp, 0
>> -- 
>> 2.21.0
>>
>>
> 
> /Jarkko
> 

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Borislav Petkov]

On Wed, Mar 10, 2021 at 02:55:55PM -0800, Yu, Yu-cheng wrote:
> > > @@ -27,6 +27,9 @@
> > >   SYM_FUNC_START(__vdso_sgx_enter_enclave)
> > >   	/* Prolog */
> > >   	.cfi_startproc
> > > +#ifdef CONFIG_X86_CET
> > > +	endbr64
> > > +#endif

You can hide this ifdeffery in a macro and have

	ENDBR64

at the callsite and define

.macro ENDBR64
#ifdef CONFIG_X86_CET
	endbr64
#endif
.endm

or so, perhaps. Ditto for endbr32.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Dave Hansen]

On 3/10/21 2:55 PM, Yu, Yu-cheng wrote:
> On 3/10/2021 2:39 PM, Jarkko Sakkinen wrote:
>> On Wed, Mar 10, 2021 at 02:05:19PM -0800, Yu-cheng Yu wrote:
>>> When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
>>> in the beginning of the function.
>>
>> OK.
>>
>> What you should do is to explain what it does and why it's needed.
>>
> 
> The endbr marks a branch target.  Without the "no-track" prefix, if an
> indirect call/jmp reaches a non-endbr opcode, a control-protection fault
> is raised.  Usually endbr's are inserted by the compiler.  For assembly,
> these have to be put in manually.  I will add this in the commit log if
> there is another revision.  Thanks!

This is close, but it's missing a detail or two that I think is
important for someone like Jarkko trying to figure out what it means for
his subsystem or driver.

I'd probably say:

ENDBR is a special new instruction for the Indirect Branch Tracking
(IBR) component of CET.  IBT prevents attacks by ensuring that (most)
indirect branches and function calls may only land at ENDBR
instructions.  Branches that don't follow the rules will result in
control flow (#CF) exceptions.

ENDBR is a noop when IBT is unsupported or disabled.  Most ENDBR
instructions are inserted automatically by the compiler, but branch
targets written in assembly must have ENDBR added manually, like this one.

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Yu, Yu-cheng]

On 3/10/2021 3:20 PM, Dave Hansen wrote:
> On 3/10/21 2:55 PM, Yu, Yu-cheng wrote:
>> On 3/10/2021 2:39 PM, Jarkko Sakkinen wrote:
>>> On Wed, Mar 10, 2021 at 02:05:19PM -0800, Yu-cheng Yu wrote:
>>>> When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
>>>> in the beginning of the function.
>>>
>>> OK.
>>>
>>> What you should do is to explain what it does and why it's needed.
>>>
>>
>> The endbr marks a branch target.  Without the "no-track" prefix, if an
>> indirect call/jmp reaches a non-endbr opcode, a control-protection fault
>> is raised.  Usually endbr's are inserted by the compiler.  For assembly,
>> these have to be put in manually.  I will add this in the commit log if
>> there is another revision.  Thanks!
> 
> This is close, but it's missing a detail or two that I think is
> important for someone like Jarkko trying to figure out what it means for
> his subsystem or driver.
> 
> I'd probably say:
> 
> ENDBR is a special new instruction for the Indirect Branch Tracking
> (IBR) component of CET.  IBT prevents attacks by ensuring that (most)
> indirect branches and function calls may only land at ENDBR
> instructions.  Branches that don't follow the rules will result in
> control flow (#CF) exceptions.
> 
> ENDBR is a noop when IBT is unsupported or disabled.  Most ENDBR
> instructions are inserted automatically by the compiler, but branch
> targets written in assembly must have ENDBR added manually, like this one.
> 

Ok, I will update.  Thanks!

--
Yu-cheng

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Jarkko Sakkinen]

On Wed, Mar 10, 2021 at 02:55:55PM -0800, Yu, Yu-cheng wrote:
> On 3/10/2021 2:39 PM, Jarkko Sakkinen wrote:
> > On Wed, Mar 10, 2021 at 02:05:19PM -0800, Yu-cheng Yu wrote:
> > > When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
> > > in the beginning of the function.
> > 
> > OK.
> > 
> > What you should do is to explain what it does and why it's needed.
> > 
> 
> The endbr marks a branch target.  Without the "no-track" prefix, if an
> indirect call/jmp reaches a non-endbr opcode, a control-protection fault is
> raised.  Usually endbr's are inserted by the compiler.  For assembly, these
> have to be put in manually.  I will add this in the commit log if there is
> another revision.  Thanks!

Thanks for the explanation. There is another revision, because this is
lacking from the commit message.

Does it do any harm to put it there unconditionally?

> 
> --
> Yu-cheng
> 
> > > 
> > > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> > > Cc: Andy Lutomirski <luto@kernel.org>
> > > Cc: Dave Hansen <dave.hansen@linux.intel.com>
> > > Cc: Jarkko Sakkinen <jarkko@kernel.org>
> > > ---
> > >   arch/x86/entry/vdso/vsgx.S | 3 +++
> > >   1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/arch/x86/entry/vdso/vsgx.S b/arch/x86/entry/vdso/vsgx.S
> > > index 86a0e94f68df..a70d4d09f713 100644
> > > --- a/arch/x86/entry/vdso/vsgx.S
> > > +++ b/arch/x86/entry/vdso/vsgx.S
> > > @@ -27,6 +27,9 @@
> > >   SYM_FUNC_START(__vdso_sgx_enter_enclave)
> > >   	/* Prolog */
> > >   	.cfi_startproc
> > > +#ifdef CONFIG_X86_CET
> > > +	endbr64
> > > +#endif
> > >   	push	%rbp
> > >   	.cfi_adjust_cfa_offset	8
> > >   	.cfi_rel_offset		%rbp, 0
> > > -- 
> > > 2.21.0
> > > 
> > > 
> > 
> > /Jarkko
> > 
> 
> 

/Jarkko

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Peter Zijlstra]

On Thu, Mar 11, 2021 at 05:36:06AM +0200, Jarkko Sakkinen wrote:
> Does it do any harm to put it there unconditionally?

Blows up your text footprint and I$ pressure. These instructions are 4
bytes each.

Aside from that, they're a NOP, so only consume front-end resources
(hopefully) on older CPUs and when IBT is disabled.

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Yu, Yu-cheng]

On 3/11/2021 12:42 AM, Peter Zijlstra wrote:
> On Thu, Mar 11, 2021 at 05:36:06AM +0200, Jarkko Sakkinen wrote:
>> Does it do any harm to put it there unconditionally?
> 
> Blows up your text footprint and I$ pressure. These instructions are 4
> bytes each.
> 
> Aside from that, they're a NOP, so only consume front-end resources
> (hopefully) on older CPUs and when IBT is disabled.
> 

Thanks Peter.  I think probably we'll do the macro Boris suggested. 
That takes care of the visual clutter, and eliminates the need of using 
.byte when the assembler is outdated.

--
Yu-cheng

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Jarkko Sakkinen]

On Wed, Mar 10, 2021 at 03:20:20PM -0800, Dave Hansen wrote:
> On 3/10/21 2:55 PM, Yu, Yu-cheng wrote:
> > On 3/10/2021 2:39 PM, Jarkko Sakkinen wrote:
> >> On Wed, Mar 10, 2021 at 02:05:19PM -0800, Yu-cheng Yu wrote:
> >>> When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
> >>> in the beginning of the function.
> >>
> >> OK.
> >>
> >> What you should do is to explain what it does and why it's needed.
> >>
> > 
> > The endbr marks a branch target.  Without the "no-track" prefix, if an
> > indirect call/jmp reaches a non-endbr opcode, a control-protection fault
> > is raised.  Usually endbr's are inserted by the compiler.  For assembly,
> > these have to be put in manually.  I will add this in the commit log if
> > there is another revision.  Thanks!
> 
> This is close, but it's missing a detail or two that I think is
> important for someone like Jarkko trying to figure out what it means for
> his subsystem or driver.
> 
> I'd probably say:
> 
> ENDBR is a special new instruction for the Indirect Branch Tracking
> (IBR) component of CET.  IBT prevents attacks by ensuring that (most)
> indirect branches and function calls may only land at ENDBR
> instructions.  Branches that don't follow the rules will result in
> control flow (#CF) exceptions.
> 
> ENDBR is a noop when IBT is unsupported or disabled.  Most ENDBR
> instructions are inserted automatically by the compiler, but branch
> targets written in assembly must have ENDBR added manually, like this one.

Thank you, this clears the whole thing a lot.

Doesn't this mean that it could be there just as well unconditionally?

/Jarkko

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Jarkko Sakkinen]

On Thu, Mar 11, 2021 at 09:42:05AM +0100, Peter Zijlstra wrote:
> On Thu, Mar 11, 2021 at 05:36:06AM +0200, Jarkko Sakkinen wrote:
> > Does it do any harm to put it there unconditionally?
> 
> Blows up your text footprint and I$ pressure. These instructions are 4
> bytes each.
> 
> Aside from that, they're a NOP, so only consume front-end resources
> (hopefully) on older CPUs and when IBT is disabled.

OK, understood, thanks for the explanation.

/Jarkko

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Jarkko Sakkinen]

On Fri, Mar 12, 2021 at 06:55:57PM +0200, Jarkko Sakkinen wrote:
> On Wed, Mar 10, 2021 at 03:20:20PM -0800, Dave Hansen wrote:
> > On 3/10/21 2:55 PM, Yu, Yu-cheng wrote:
> > > On 3/10/2021 2:39 PM, Jarkko Sakkinen wrote:
> > >> On Wed, Mar 10, 2021 at 02:05:19PM -0800, Yu-cheng Yu wrote:
> > >>> When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
> > >>> in the beginning of the function.
> > >>
> > >> OK.
> > >>
> > >> What you should do is to explain what it does and why it's needed.
> > >>
> > > 
> > > The endbr marks a branch target.  Without the "no-track" prefix, if an
> > > indirect call/jmp reaches a non-endbr opcode, a control-protection fault
> > > is raised.  Usually endbr's are inserted by the compiler.  For assembly,
> > > these have to be put in manually.  I will add this in the commit log if
> > > there is another revision.  Thanks!
> > 
> > This is close, but it's missing a detail or two that I think is
> > important for someone like Jarkko trying to figure out what it means for
> > his subsystem or driver.
> > 
> > I'd probably say:
> > 
> > ENDBR is a special new instruction for the Indirect Branch Tracking
> > (IBR) component of CET.  IBT prevents attacks by ensuring that (most)
> > indirect branches and function calls may only land at ENDBR
> > instructions.  Branches that don't follow the rules will result in
> > control flow (#CF) exceptions.
> > 
> > ENDBR is a noop when IBT is unsupported or disabled.  Most ENDBR
> > instructions are inserted automatically by the compiler, but branch
> > targets written in assembly must have ENDBR added manually, like this one.
> 
> Thank you, this clears the whole thing a lot.
> 
> Doesn't this mean that it could be there just as well unconditionally?

Please, ignore the question (got the answer).

/Jarkko

Re: [PATCH v22 8/8] x86/vdso: Add ENDBR64 to __vdso_sgx_enter_enclave

[Dave Hansen]

On 3/12/21 8:55 AM, Jarkko Sakkinen wrote:
>> ENDBR is a special new instruction for the Indirect Branch Tracking
>> (IBT) component of CET.  IBT prevents attacks by ensuring that (most)
>> indirect branches and function calls may only land at ENDBR
>> instructions.  Branches that don't follow the rules will result in
>> control flow (#CF) exceptions.
>>
>> ENDBR is a noop when IBT is unsupported or disabled.  Most ENDBR
>> instructions are inserted automatically by the compiler, but branch
>> targets written in assembly must have ENDBR added manually, like this one.
> Thank you, this clears the whole thing a lot.
> 
> Doesn't this mean that it could be there just as well unconditionally?

It could be there unconditionally.  But, I think it's still worth the
#ifdef just out of the principle of being as tidy as possible.  The
#ifdef is basically as low cost and low complexity as you get.  It is
also somewhat self-documenting: "This instruction is only necessary when
your CPU supports IBT".