Re: [RFC PATCH v2 22/27] x86/cet/ibt: User-mode indirect branch tracking support
From: Jann Horn <jannh@google.com>
Date: 2018-07-11 21:07:40
Also in:
linux-arch, linux-doc, linux-mm, lkml
On Tue, Jul 10, 2018 at 3:31 PM Yu-cheng Yu [off-list ref] wrote:
Add user-mode indirect branch tracking enabling/disabling and supporting routines. Signed-off-by: H.J. Lu <redacted> Signed-off-by: Yu-cheng Yu <redacted>
[...]
quoted hunk ↗ jump to hunk
diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c index 4eba7790c4e4..8bbd63e1a2ba 100644 --- a/arch/x86/kernel/cet.c +++ b/arch/x86/kernel/cet.c
[...]
+static unsigned long ibt_mmap(unsigned long addr, unsigned long len)
+{
+ struct mm_struct *mm = current->mm;
+ unsigned long populate;
+
+ down_write(&mm->mmap_sem);
+ addr = do_mmap(NULL, addr, len, PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_PRIVATE,
+ VM_DONTDUMP, 0, &populate, NULL);
+ up_write(&mm->mmap_sem);
+
+ if (populate)
+ mm_populate(addr, populate);
+
+ return addr;
+}Is this thing going to stay writable? Will any process with an IBT bitmap be able to disable protections by messing with the bitmap even if the lock-out mode is active? If so, would it perhaps make sense to forbid lock-out mode if an IBT bitmap is active, to make it clear that effective lock-out is impossible in that state?