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]

Message-ID: <CAOyeoRWuHyhoy6NB=O+ekQMhBFngozKoanWzArxgBk4DH2hdtg@mail.gmail.com>
Date:   Mon, 3 Jun 2019 10:30:20 -0700
From:   Eric Hankland <ehankland@...gle.com>
To:     Wei Wang <wei.w.wang@...el.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 Sat, Jun 1, 2019 at 3:50 AM Wei Wang <wei.w.wang@...el.com> wrote:
>
> 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'm not disputing the spec with regards to AnyThread=0; my point is
that LLC contention can be quantified using the PMU regardless of
whether or not you are measuring only the logical CPU you are running
on.

>  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.

If you return non-zero in intel_pmu_set_msr(), KVM emulates a gp
fault. Which as you said signals that something went wrong to the
guest. However, older guests with panic_on_oops=1 (which is apparently
default on RHEL 6) will panic if they get a gpfault while trying to do
a wrmsr (see the "Carry on after a non-"safe" MSR access fails without
!panic_on_oops" patch). I think that not panicking guests is probably
preferable to communicating that we weren't able to program the event.

Eric