On Fri, Jun 12, 2020 at 10:39:35PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 12, 2020 at 07:48:01PM +0200, Borislav Petkov wrote:
> > On Fri, Jun 12, 2020 at 10:20:03AM -0700, Linus Torvalds wrote:
> > > Since you already added the filtering, this looks fairly sane.
> > >
> > > IOW, what MSR's do
On Fri, Jun 12, 2020 at 1:41 PM Peter Zijlstra wrote:
>
> On Fri, Jun 12, 2020 at 07:48:01PM +0200, Borislav Petkov wrote:
> > On Fri, Jun 12, 2020 at 10:20:03AM -0700, Linus Torvalds wrote:
> > > Since you already added the filtering, this looks fairly sane.
> > >
> > > IOW, what MSR's do we expe
On Fri, Jun 12, 2020 at 07:48:01PM +0200, Borislav Petkov wrote:
> On Fri, Jun 12, 2020 at 10:20:03AM -0700, Linus Torvalds wrote:
> > Since you already added the filtering, this looks fairly sane.
> >
> > IOW, what MSR's do we expect people to maybe write to normally? You
> > added MSR_IA32_ENERG
On Fri, Jun 12, 2020 at 07:48:01PM +0200, Borislav Petkov wrote:
> > So the first phase might be to introduce this, but have the default
> > for non-recognized MSR's be "log", not "deny".
>
> Ok. How are we going to "learn" about those non-recognized MSRs? Ask
> people to send us a note to lkml so
On Fri, Jun 12, 2020 at 10:43:07AM -0700, Sean Christopherson wrote:
> The problem is a fault on WRMSR doesn't mean the MSR doesn't exist, it only
> means WRMSR faulted. WRMSR can for all intents and purpose trigger completely
> arbitrary microcode flows, e.g. WRMSR 0x79 can fundamentally change t
On Fri, Jun 12, 2020 at 10:20:03AM -0700, Linus Torvalds wrote:
> Since you already added the filtering, this looks fairly sane.
>
> IOW, what MSR's do we expect people to maybe write to normally? You
> added MSR_IA32_ENERGY_PERF_BIAS as an allowed MST, maybe there are
> others?
Right, this MSR i
On Fri, Jun 12, 2020 at 07:03:03PM +0200, Borislav Petkov wrote:
> On Fri, Jun 12, 2020 at 09:57:09AM -0700, Sean Christopherson wrote:
> > DS_AREA takes a virtual (linear) address, i.e. the address can be legal from
> > the CPUs perspective but still lead to a #PF due to the address not being
> >
On Fri, Jun 12, 2020 at 3:50 AM Borislav Petkov wrote:
>
> Disable writing to MSRs from userspace by default. Writes can still be
> allowed by supplying the allow_writes=1 module parameter and the kernel
> will be tainted so that it shows in oopses.
Since you already added the filtering, this loo
On Fri, Jun 12, 2020 at 09:57:09AM -0700, Sean Christopherson wrote:
> DS_AREA takes a virtual (linear) address, i.e. the address can be legal from
> the CPUs perspective but still lead to a #PF due to the address not being
> mapped in the page tables.
It's not that - peterz and tglx - and I assum
On Fri, Jun 12, 2020 at 06:46:02PM +0200, Borislav Petkov wrote:
> On Fri, Jun 12, 2020 at 09:34:06AM -0700, Sean Christopherson wrote:
> > The kernel should be tainted if the WRMSR is attempted, regardless of
> > whether it succeeds, and it should happen before the WRMSR. E.g. pointing
> > MSR_IA
On Fri, Jun 12, 2020 at 09:34:06AM -0700, Sean Christopherson wrote:
> The kernel should be tainted if the WRMSR is attempted, regardless of
> whether it succeeds, and it should happen before the WRMSR. E.g. pointing
> MSR_IA32_DS_AREA at a bad address will likely cause an OOPS on the #PF
If the
On Fri, Jun 12, 2020 at 12:50:26PM +0200, Borislav Petkov wrote:
> @@ -95,11 +114,18 @@ static ssize_t msr_write(struct file *file, const char
> __user *buf,
> err = wrmsr_safe_on_cpu(cpu, reg, data[0], data[1]);
> if (err)
> break;
> +
>
12 matches
Mail list logo
