Re: CET/IBT support and live-patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 23 Nov 2021, Peter Zijlstra wrote:

> On Tue, Nov 23, 2021 at 10:58:57AM +0100, Miroslav Benes wrote:
> > [ adding more CCs ]
> > 
> > On Mon, 22 Nov 2021, joao@xxxxxxxxxxxxxxxxxx wrote:
> > 
> > > Hi Miroslav, Petr and Nicolai,
> > > 
> > > Long time no talk, I hope you are all still doing great :)
> > 
> > Everything great here :)
> > 
> > > So, we have been cooking a few patches for enabling Intel CET/IBT support in
> > > the kernel. The way IBT works is -- whenever you have an indirect branch, the
> > > control-flow must land in an endbr instruction. The idea is to constrain
> > > control-flow in a way to make it harder for attackers to achieve meaningful
> > > computation through pointer/memory corruption (as in, an attacker that can
> > > corrupt a function pointer by exploiting a memory corruption bug won't be able
> > > to execute whatever piece of code, being restricted to jump into endbr
> > > instructions). To make the allowed control-flow graph more restrict, we are
> > > looking into how to minimize the number of endbrs in the final kernel binary
> > > -- meaning that if a function is never called indirectly, it shouldn't have an
> > > endbr instruction, thus increasing the security guarantees of the hardware
> > > feature.
> > > 
> > > Some ref about what is going on --
> > > https://lore.kernel.org/lkml/20211122170805.149482391@xxxxxxxxxxxxx/T/
> > 
> > Yes, I noticed something was happening again. There was a thread on this 
> > in February https://lore.kernel.org/all/20210207104022.GA32127@xxxxxxx/ 
> > and some concerns were raised back then around fentry and int3 patching if 
> > I remember correctly. Is this still an issue?
> 
> The problem was bpf, and probably still is. I've not come around to
> looking at it. Asusming fentry is at +0 is silly (although I would like
> to see that restored for other reasons), but bpf will also need to emit
> ENDBR at least at the start of every JIT'ed program, because entry into
> them is through an indirect branch.
> 
> If nobody beats me to it, I'll get around to it eventually.

Ok. And we would need something like the following for the livepatch (not 
even compile tested).

---

diff --git a/arch/powerpc/include/asm/livepatch.h b/arch/powerpc/include/asm/livepatch.h
index 4fe018cc207b..7b9dcd51af32 100644
--- a/arch/powerpc/include/asm/livepatch.h
+++ b/arch/powerpc/include/asm/livepatch.h
@@ -19,16 +19,6 @@ static inline void klp_arch_set_pc(struct ftrace_regs *fregs, unsigned long ip)
 	regs_set_return_ip(regs, ip);
 }
 
-#define klp_get_ftrace_location klp_get_ftrace_location
-static inline unsigned long klp_get_ftrace_location(unsigned long faddr)
-{
-	/*
-	 * Live patch works only with -mprofile-kernel on PPC. In this case,
-	 * the ftrace location is always within the first 16 bytes.
-	 */
-	return ftrace_location_range(faddr, faddr + 16);
-}
-
 static inline void klp_init_thread_info(struct task_struct *p)
 {
 	/* + 1 to account for STACK_END_MAGIC */
diff --git a/kernel/livepatch/patch.c b/kernel/livepatch/patch.c
index fe316c021d73..81cd9235e160 100644
--- a/kernel/livepatch/patch.c
+++ b/kernel/livepatch/patch.c
@@ -127,15 +127,18 @@ static void notrace klp_ftrace_handler(unsigned long ip,
 /*
  * Convert a function address into the appropriate ftrace location.
  *
- * Usually this is just the address of the function, but on some architectures
- * it's more complicated so allow them to provide a custom behaviour.
+ * Usually this is just the address of the function, but there are some
+ * exceptions.
+ *
+ *   * PPC - live patch works only with -mprofile-kernel. In this case,
+ *     the ftrace location is always within the first 16 bytes.
+ *   * x86_64 with CET/IBT enabled - there is ENDBR instruction at +0 offset.
+ *     __fentry__ follows it.
  */
-#ifndef klp_get_ftrace_location
-static unsigned long klp_get_ftrace_location(unsigned long faddr)
+static inline unsigned long klp_get_ftrace_location(unsigned long faddr)
 {
-	return faddr;
+	return ftrace_location_range(faddr, faddr + 16);
 }
-#endif
 
 static void klp_unpatch_func(struct klp_func *func)
 {
 




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux