Date: Fri, 7 Aug 2020 19:19:25 +0200 From: Solar Designer <solar@...nwall.com> To: Kees Cook <keescook@...omium.org> Cc: lkrg-users@...ts.openwall.com, Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...e.de> Subject: Re: lkrg: Fix build LKRG for kernel 5.8+ On Wed, Aug 05, 2020 at 01:53:39PM -0700, Kees Cook wrote: > On Wed, Aug 05, 2020 at 08:48:00PM +0200, Solar Designer wrote: > > We use native_write_cr4() via its wrapper __write_cr4() (in a kernel > > header file) to restore SMEP and/or SMAP if these are unexpectedly > > disabled yet kernel panic on this event is not enabled in LKRG > > configuration (by default it is enabled). > > Is the existing bit pinning not sufficient for lkrg? I expect it's sufficient against the specific LKRG bypass that prompted some related hardening of LKRG 1.5 years ago, roughly when the pinning was being introduced into the kernel: https://www.openwall.com/lists/lkrg-users/2019/02/20/2 "On a related note, today on kernel-hardening: Subject: [PATCH] x86/asm: Pin sensitive CR4 bits https://www.openwall.com/lists/kernel-hardening/2019/02/20/1 As I understand, this would break the gadget this exploit uses to disable SMEP." However, LKRG also supports older kernels, it makes no assumptions on how the value of CR4 might have changed unexpectedly (via this gadget or not), and it supports a configuration where it'd restore SMEP and/or SMAP. It'd be weird to have that configuration unsupported on 5.8+. IIRC, back when you worked on the pinning, I estimated the probability of CR4-writing gadgets being present in the kernel image inadvertently (not at original instruction boundaries), and it looked significant. So now it looks like we should either hack our way around the symbol unexport (there are still a few easy ways to find and use an unexported symbol, which we already use for some other symbols that we need) or introduce our own native_write_cr4() with our own pinning similar to upstream's (or else we'd potentially make things worse security-wise). Requiring CONFIG_LKDTM isn't an option long-term as we can't expect distro kernels to enable that, and we want to support distro kernels. Well, maybe it'd be an option if native_write_cr4 is exported in the next release again, and no major distro uses 5.8. Anyway, I think we'll take care of this, no problem. Like I wrote, I only CC'ed as a JFYI. Things would become worse for us if upstream proceeds to fight modules' access to unexported symbols more than in the nominal way it does now. Surely there are no security reasons for that fight, but we're concerned this might not be understood that way by all. The recent unexport of kallsyms_lookup_name, which we worked around alright (we still locate and use this function to lookup the rest), is a worrisome precedent, but at least that was (correctly) not claimed to be done for security (but for Google's needs in the Android ecosystem). Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.