linux-kernel - Re: [PATCH v3 04/17] perf: x86/ds: Handle guest PEBS overflow PMI and inject it to guest

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 15 Jan 2021 15:44:40 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Xu, Like" <like.xu@...el.com>
Cc:     Like Xu <like.xu@...ux.intel.com>,
        Kan Liang <kan.liang@...ux.intel.com>,
        Paolo Bonzini <pbonzini@...hat.com>, eranian@...gle.com,
        kvm@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Andi Kleen <andi@...stfloor.org>, wei.w.wang@...el.com,
        luwei.kang@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 04/17] perf: x86/ds: Handle guest PEBS overflow PMI
 and inject it to guest

On Fri, Jan 15, 2021 at 10:30:13PM +0800, Xu, Like wrote:

> > Are you sure? Spurious NMI/PMIs are known to happen anyway. We have far
> > too much code to deal with them.
> 
> https://lore.kernel.org/lkml/20170628130748.GI5981@leverpostej/T/
> 
> In the rr workload, the commit change "the PMI interrupts in skid region
> should be dropped"
> is reverted since some users complain that:
> 
> > It seems to me that it might be reasonable to ignore the interrupt if
> > the purpose of the interrupt is to trigger sampling of the CPUs
> > register state.  But if the interrupt will trigger some other
> > operation, such as a signal on an fd, then there's no reason to drop
> > it.
> 
> I assume that if the PMI drop is unacceptable, either will spurious PMI
> injection.
> 
> I'm pretty open if you insist that we really need to do this for guest PEBS
> enabling.

That was an entirely different issue. We were dropping events on the
floor because they'd passed priv boundaries. So there was an actual
event, and we made it go away.

What we're talking about here is raising an PMI with BUFFER_OVF set,
even if the DS is empty. That should really be harmless. We'll take the
PMI, find there's nothing there, and do nothing.