linux-kernel - Re: [PATCH] KVM: x86/pmu: Add '.exclude_hv = 1' for guest perf

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] [day] [month] [year] [list]

Message-ID: <40005c08-27ec-edcd-503e-9d2eaac7d2a4@redhat.com>
Date:   Wed, 12 Aug 2020 15:51:13 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     peterz@...radead.org
Cc:     Like Xu <like.xu@...ux.intel.com>, Yao <yao.jin@...ux.intel.com>,
        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>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] KVM: x86/pmu: Add '.exclude_hv = 1' for guest perf_event

On 12/08/20 15:31, peterz@...radead.org wrote:
> This isn't about x86, I want these checks in generic code. We have the
> flag, it needs checking.
> 
> unpriv users have no busniess getting anything from a possible hv.

Ah ok if it's generic that sounds good.

>> That would be the case of an unprivileged user that wants to measure
>> performance of its guests.
> 
> An unpriv user can run guests?

Sure, on most distros /dev/kvm is either 0666 or 0660, usually with
group kvm if it's 0660.  To run a guest you might have to be in group
kvm, but it does not require either root or CAP_SOMETHING.

>>> Also, exclude_host is really poorly defined:
>>>
>>>   https://lkml.kernel.org/r/20200806091827.GY2674@hirez.programming.kicks-ass.net
>>>
>>>   "Suppose we have nested virt:
>>>
>>> 	  L0-hv
>>> 	  |
>>> 	  G0/L1-hv
>>> 	     |
>>> 	     G1
>>>
>>>   And we're running in G0, then:
>>>
>>>   - 'exclude_hv' would exclude L0 events
>>>   - 'exclude_host' would ... exclude L1-hv events?
>>>   - 'exclude_guest' would ... exclude G1 events?
>>
>> From the point of view of G0, L0 *does not exist at all*.  You just
>> cannot see L0 events if you're running in G0.
> 
> On x86, probably, in general, I'm not at all sure, we have that
> exclude_hv flag after all.

No, and you can quote me on that: exclude_hv is *not* about excluding
the hypervisor from a guest.  It's about excluding the part of _your_
kernel which runs in a "more privileged" level (EL2 on ARM, HV on POWER).

>> exclude_host/exclude_guest are the right definition.
> 
> For what?

I meant in the nested virt case you drew above.

> I still think exclude_host is absolute shit. If you set it,
> you'll not get anything even without virt.

If you dislike the name you can change it to only_guest.  Anybody who
does not do virt just leaves it zero and is happy.  Anybody who does not
do virt and sets it gets what they expect (or deserve).  But this
definition is the same as exclude_host, and it's the correct one.

> If, as you seem to imply above, that unpriv users can create guests,
> then maybe so, but if I look at /dev/kvm it seems to have 0660
> permissions and thus really requires privileges.

Since you can be non-root and you don't need any capability either, it
doesn't require what the kernel considers to be privilege.

Paolo