lkml.org 
[lkml]   [2020]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1] x86: Pin cr4 FSGSBASE
On Tue, May 26, 2020 at 10:17:52AM +0200, Greg KH wrote:
> On Tue, May 26, 2020 at 09:57:36AM +0200, Peter Zijlstra wrote:
> > On Tue, May 26, 2020 at 08:56:18AM +0200, Greg KH wrote:
> > > On Mon, May 25, 2020 at 10:28:48PM -0700, Andi Kleen wrote:
> > > > From: Andi Kleen <ak@linux.intel.com>
> > > >
> > > > Since there seem to be kernel modules floating around that set
> > > > FSGSBASE incorrectly, prevent this in the CR4 pinning. Currently
> > > > CR4 pinning just checks that bits are set, this also checks
> > > > that the FSGSBASE bit is not set, and if it is clears it again.
> > >
> > > So we are trying to "protect" ourselves from broken out-of-tree kernel
> > > modules now? Why stop with this type of check, why not just forbid them
> > > entirely if we don't trust them? :)
> >
> > Oh, I have a bunch of patches pending for that :-)
>
> Ah, I thought I had seen something like that go by a while ago.
>
> It's sad that we have to write a "don't do stupid things" checker for
> kernel modules now :(

Because people... they get stuff from the interweb and run it :/ The
days that admins actually knew what they're doing is long long gone.

> > It will basically decode the module text and refuse to load the module
> > for most CPL0 instruction.
>
> Ok, so why would Andi's patch even be needed then? Andi, why post this?

Andi's patch cures a particularly bad module that floats around that
people use, probably without being aware that it's an insta-root hole.

My patches will be a while (too many things in the fire :/) and will
certainly not be for stable.

\
 
 \ /
  Last update: 2020-05-26 11:23    [W:0.056 / U:0.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site