Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-27 Thread Wojtek Porczyk
On Wed, May 27, 2020 at 09:07:55AM +0200, Greg KH wrote: > On Tue, May 26, 2020 at 07:24:03PM +0200, Wojtek Porczyk wrote: > > On Tue, May 26, 2020 at 06:32:35PM +0200, Greg KH wrote: > > > On Tue, May 26, 2020 at 08:48:35AM -0700, Andi Kleen wrote: > > > > On Tue, May 26, 2020 at 08:56:18AM +0200,

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-27 Thread Peter Zijlstra
On Tue, May 26, 2020 at 04:14:25PM -0700, Andi Kleen wrote: > > And if this is going to be more permanent, we can separate the mask > > (untested): > > The FSGSBASE one should not be permanent, it will be replaced > with the full FSGSBASE patches that set that bit correctly. Well, even with full

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-27 Thread Greg KH
On Tue, May 26, 2020 at 07:24:03PM +0200, Wojtek Porczyk wrote: > On Tue, May 26, 2020 at 06:32:35PM +0200, Greg KH wrote: > > On Tue, May 26, 2020 at 08:48:35AM -0700, Andi Kleen wrote: > > > On Tue, May 26, 2020 at 08:56:18AM +0200, Greg KH wrote: > > > > On Mon, May 25, 2020 at 10:28:48PM -0700,

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Andi Kleen
> And if this is going to be more permanent, we can separate the mask > (untested): The FSGSBASE one should not be permanent, it will be replaced with the full FSGSBASE patches that set that bit correctly. I was a bit wary of enforcing it for all bits, there might be other CR4 bits which have ben

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Greg KH
On Tue, May 26, 2020 at 09:15:04AM -0700, Kees Cook wrote: > On Tue, May 26, 2020 at 08:56:18AM +0200, Greg KH wrote: > > What about those systems that panic-on-warn? > > This is (modulo the general discussion about whether it's the right > way to check) the correct use for WARN*(). It's an undesi

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Wojtek Porczyk
On Tue, May 26, 2020 at 06:32:35PM +0200, Greg KH wrote: > On Tue, May 26, 2020 at 08:48:35AM -0700, Andi Kleen 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 > > > > > > > > Since ther

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Kees Cook
On Mon, May 25, 2020 at 10:28:48PM -0700, Andi Kleen wrote: > From: Andi Kleen > > 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 bi

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Greg KH
On Tue, May 26, 2020 at 08:48:35AM -0700, Andi Kleen 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 > > > > > > Since there seem to be kernel modules floating around that set > > > FSGSBASE i

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Kees Cook
On Tue, May 26, 2020 at 08:48:35AM -0700, Andi Kleen 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: > > > + if (val & X86_CR4_FSGSBASE) { > > > + WARN_ONCE(1, "CR4 unexpectedly set FSGSBASE!?\

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Kees Cook
On Tue, May 26, 2020 at 08:56:18AM +0200, Greg KH wrote: > What about those systems that panic-on-warn? This is (modulo the general discussion about whether it's the right way to check) the correct use for WARN*(). It's an undesirable system state; people choosing panic-on-warn want this: https://

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Andi Kleen
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 > > > > Since there seem to be kernel modules floating around that set > > FSGSBASE incorrectly, prevent this in the CR4 pinning. Currently > > CR4 pinning j

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Greg KH
On Tue, May 26, 2020 at 11:17:45AM +0200, Peter Zijlstra wrote: > 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 -0

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Peter Zijlstra
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 > > > > > > > > Since

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Greg KH
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 > > > > > > Since there seem to be kernel modules floating around that set > > > FSGSBA

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-26 Thread Peter Zijlstra
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 > > > > Since there seem to be kernel modules floating around that set > > FSGSBASE incorrectly, prevent this in the CR4 pinning. Currently > > CR4 pinning j

Re: [PATCH v1] x86: Pin cr4 FSGSBASE

2020-05-25 Thread Greg KH
On Mon, May 25, 2020 at 10:28:48PM -0700, Andi Kleen wrote: > From: Andi Kleen > > 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 bi