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,
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
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,
> 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
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
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
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
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
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!?\
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://
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
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
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
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
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
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
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 bit is not set, and if it is clears it again.
Note this patch will need t
17 matches
Mail list logo
