linux-kernel - Re: [PATCH v1] KVM: x86: PMU Whitelist

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]

Date:   Sat, 01 Jun 2019 18:55:23 +0800
From:   Wei Wang <wei.w.wang@...el.com>
To:     Eric Hankland <ehankland@...gle.com>
CC:     pbonzini@...hat.com, rkrcmar@...hat.com,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v1] KVM: x86: PMU Whitelist

On 06/01/2019 03:59 AM, Eric Hankland wrote:
>
> With anythread=0, I'm not aware of any events that directly give info
> about other VMs, but monitoring events related to shared resources
> (e.g. LLC References and LLC Misses) could indirectly give you info
> about how heavily other users are using that resource.

My question is that have we proved that this indirect info leakage 
indeed happens?
The spec states that the counter will count the related events generated by
the logical CPU with AnyThread=0. I would be inclined to trust the 
hardware behavior
documented in the spec unless we could prove there is a problem.

>
> I tried returning 1 when the guest tries to write the eventsel msr for
> a disallowed event - the behavior on modern guest kernels looks
> reasonable (warns once about an unchecked MSR access error), but it
> looks like guests using older kernels (older than 2016) might panic
> due to the gpfault (not to mention I'm not sure about the behavior on
> non-linux kernels). So I'm hesitant to return 1 - what do you think?

 From the guest point of view, returning 0 means that the event counting 
is running well.
That is, the guest is expecting to get some count numbers. So better not 
to zero the value
when the guest does rdpmc/rdmsr to get the count in this case.

I think we could just ensure "AnyThread=0" in the config, and create the 
kernel
counter as usual.

> I also looked into moving from a vcpu ioctl to a vm ioctl - I can send
> out a version of the patch with this change once we settle on the
> other issues. It will involve some extra locking every time the
> counters are programmed to ensure the whitelist or blacklist isn't
> removed during access.
>

Yes, the above discussion needs to be done first.

Best,
Wei