linux-kernel - Re: [PATCH -v2.1] x86/msr: Filter MSR writes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200714164612.GA28474@agluck-desk2.amr.corp.intel.com>
Date:   Tue, 14 Jul 2020 09:46:12 -0700
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Chris Down <chris@...isdown.name>
Cc:     Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org,
        sean.j.christopherson@...el.com, torvalds@...ux-foundation.org,
        x86@...nel.org, kernel-team@...com,
        Matthew Garrett <matthewgarrett@...gle.com>
Subject: Re: [PATCH -v2.1] x86/msr: Filter MSR writes

On Tue, Jul 14, 2020 at 05:04:48PM +0100, Chris Down wrote:
> Borislav Petkov writes:
> > On Tue, Jul 14, 2020 at 01:19:55PM +0100, Chris Down wrote:
> > > That is, even with pr_err_ratelimited, we still end up logging on basically
> > > every single write, even though it's from the same TGID writing to the same
> > > MSRs, and end up becoming >80% of kmsg.
> > > 
> > > Of course, one can boot with `allow_writes=1` to avoid these messages at
> > 
> > Yes, use that.
> > 
> > From a quick scan over that "tool" you pointed me at, it pokes at some
> > MSRs from userspace which the kernel *also* writes to and this is
> > exactly what should not be allowed.
> 
> I don't think we're in disagreement about that. My concern is strictly about
> the amount of spam caused for some of those existing use cases during the
> transition phase. People should know that their tools would break, but there
> shouldn't be so many messages generated that it inevitably pushes other
> useful information out of the kmsg buffer.

Maybe we just need smarter filtering of warnings.  It doesn't
seem at all useful to warn for the same MSR 1000's of times.
Maybe keep a count of warnings for each MSR and just stop
all reports when reach a threshold?

-Tony