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:   Mon, 24 Jun 2019 17:32:41 -0700
From:   Eric Hankland <ehankland@...gle.com>
To:     Wei Wang <wei.w.wang@...el.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, rkrcmar@...hat.com,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v1] KVM: x86: PMU Whitelist

Thanks for your feedback - I'll send out an updated version
incorporating your comments shortly (assuming you don't have more
after this).

> > +struct kvm_pmu_whitelist {
> > +       __u64 event_mask;
>
> Is this "ARCH_PERFMON_EVENTSEL_EVENT | ARCH_PERFMON_EVENTSEL_UMASK"?

In most cases, I envision this being the case, but it's possible users
may want other bits - see response to the next question below.

> > +       __u16 num_events;
> > +       __u64 events[0];
>
> Can this be __u16?
> The lower 16 bits (umask+eventsel) already determines what the event is.

It looks like newer AMD processors also use bits 32-35 for eventsel
(see AMD64_EVENTSEL_EVENT/AMD64_RAW_EVENT_MASK in
arch/x86/include/asm/perf_event.h or a recent reference guide), though
it doesn't look like this has made it to pmu_amd.c in kvm yet.
Further, including the whole 64 bits could enable whitelisting some
events with particular modifiers (e.g. in_tx=0, but not in_tx=1). I'm
not sure if whitelisting with specific modifiers will be necessary,
but we definitely need more than u16 if we want to support any AMD
events that make use of those bits in the future.

> > +       struct kvm_pmu_whitelist *whitelist;
>
> This could be per-VM and under rcu?
I'll try this out in the next version.

> Why not moving this filter to reprogram_gp_counter?
>
> You could directly compare "unit_mask, event_sel"  with whitelist->events[i]
The reason is that this approach provides uniform behavior whether an
event is programmed on a fixed purpose counter vs a general purpose
one. Though I admit it's unlikely that instructions retired/cycles
wouldn't be whitelisted (and ref cycles can't be programmed on gp
counters), so it wouldn't be missing too much if I do move this to
reprogram_gp_counter. What do you think?

> I would directly return -EFAULT here.
>
> Same here.

Sounds good - I'll fix that in the next version.

> > +       pmu->whitelist = new;
>
> Forgot to copy the whitelist-ed events to new?
Yep, somehow I deleted the lines that did this - thanks for pointing it out.