linux-kernel - Re: [PATCH v2 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <7b47b5c5-8e38-ce73-d905-47176734b1d8@intel.com>
Date:   Thu, 19 Nov 2020 09:36:58 +0800
From:   "Xu, Like" <like.xu@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Like Xu <like.xu@...ux.intel.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Kan Liang <kan.liang@...ux.intel.com>, luwei.kang@...el.com,
        Thomas Gleixner <tglx@...utronix.de>, wei.w.wang@...el.com,
        Tony Luck <tony.luck@...el.com>,
        Stephane Eranian <eranian@...gle.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 04/17] perf: x86/ds: Handle guest PEBS overflow PMI and
 inject it to guest

On 2020/11/19 2:07, Peter Zijlstra wrote:
> On Thu, Nov 19, 2020 at 12:15:09AM +0800, Like Xu wrote:
>
>>> ISTR there was lots of fail trying to virtualize it earlier. What's
>>> changed? There's 0 clues here.
>> Ah, now we have EPT-friendly PEBS facilities supported since Ice Lake
>> which makes guest PEBS feature possible w/o guest memory pinned.
> OK.
>
>>> Why are the host and guest DS area separate, why can't we map them to
>>> the exact same physical pages?
>> If we map both guest and host DS_AREA to the exact same physical pages,
>> - the guest can access the host PEBS records, which means that the host
>> IP maybe leaked, because we cannot predict the time guest drains records and
>> it would be over-designed to clean it up before each vm-entry;
>> - different tasks/vcpus on the same pcpu cannot share the same PEBS DS
>> settings from the same physical page. For example, some require large
>> PEBS and reset values, while others do not.
>>
>> Like many guest msrs, we use the separate guest DS_AREA for the guest's
>> own use and it avoids mutual interference as little as possible.
> OK, but the code here wanted to inspect the guest DS from the host. It
> states this is somehow complicated/expensive.
Yes, it's expensive to inspect guest DS in the NMI handler and also
unsafe to call sleepable EPT page fault handler in the NMI context.

So in this version, we propose to move this complicated part to the KVM
and I think the overhead is acceptable for the cross-mapped cases.

The bad thing is we will not be able to distinguish whether PEBS PMI is from
guest or host once there's a host PEBS counter enabled on the same CPU
and we may fix it later w/ your ideas.

> But surely we can at the
> very least map the first guest DS page somewhere so we can at least
> access the control bits without too much magic.
I am not sure whether the first mapped guest DS page can help
the guest PEBS to keep working from beginning to end since
later host may not map guest DS page on the physical one
and currently KVM couldn't control it fine-grained.

This version could also avoid attacks from malicious guests
by keeping its control bits in its guest space.

Thanks,
Like Xu