From: ehankland
Updates KVM_CAP_PMU_EVENT_FILTER so it can also whitelist or blacklist
fixed counters.
Signed-off-by: ehankland
---
Documentation/virtual/kvm/api.txt | 13 -
arch/x86/include/uapi/asm/kvm.h | 9 ++---
arch/x86/kvm/pmu.c| 30 +++
> Let's just implement the bitmap of fixed counters (it's okay to follow
> the same action as gp counters), and add it to struct
> kvm_pmu_event_filter. While at it, we can add a bunch of padding u32s
> and a flags field that can come in handy later (it would fail the ioctl
> if nonzero).
>
> Wei,
> I think just disabling guest cpuid might not be enough, since guest
> could write to the msr without checking the cpuid.
>
> Why not just add a bitmap for fixed counter?
> e.g. fixed_counter_reject_bitmap
>
> At the beginning of reprogram_fixed_counter, we could add the check:
>
> if (test_bit(id
Thanks for your help. The "type"->"action" change and constant
renaming sound good to me.
On Thu, Jul 11, 2019 at 4:58 AM Paolo Bonzini wrote:
>
> On 11/07/19 03:25, Eric Hankland wrote:
> > - Add a VM ioctl that can control which events the guest can moni
- Add a VM ioctl that can control which events the guest can monitor.
Signed-off-by: ehankland
---
Changes since v1:
-Moved to a vm ioctl rather than a vcpu one
-Changed from a whitelist to a configurable filter which can either be
white or black
-Only restrict GP counters since fixed counters re
> Actually I have another thing to discuss:
> probably we could consider to make this filter list white/black configurable
> from userspace. For example, userspace option: filter-list=white/black
Works for me. I'll include this in the next version.
> Probably we don't need this field to be passed
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 envisi
> Consider what happens when tmp.num_events is large enough to wrap size.
> I suspect that's a kernel exploit as written.
Thanks for pointing this out - I'll fix it in the next iteration.
> Also don't you need to copy tmp to new?
Yep - somehow I accidentally deleted the lines that did this before
t 12:31 AM Wei Wang wrote:
>
> On 06/06/2019 05:35 AM, Eric Hankland wrote:
> >>> Right - I'm aware there are other ways of detecting this - it's still
> >>> a class of events that some people don't want to surface. I'll ask if
> >>> there
>> Right - I'm aware there are other ways of detecting this - it's still
>> a class of events that some people don't want to surface. I'll ask if
>> there are any better examples.
I asked and it sounds like we are treating all events as potentially
insecure until they've been reviewed. If Intel we
On Mon, Jun 3, 2019 at 9:37 PM Wei Wang wrote:
> So, I'm not sure if "quantifying LLC contention" has been proved to
> be a real issue. If this is considered to be an issue:
>
> - without PMU, we could also write a piece of software to run in the
> guest to quantify that contention (e.g. by analy
On Sat, Jun 1, 2019 at 3:50 AM Wei Wang 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 beha
On Thu, May 30, 2019 at 5:57 PM Wei Wang wrote:
>
> On 05/30/2019 01:11 AM, Eric Hankland wrote:
> > On Wed, May 29, 2019 at 12:49 AM Wei Wang wrote:
> >> On 05/29/2019 02:14 AM, Eric Hankland wrote:
> >>> On Mon, May 27, 2019 at 6:56 PM Wei Wang wrote:
&g
On Wed, May 29, 2019 at 12:49 AM Wei Wang wrote:
>
> On 05/29/2019 02:14 AM, Eric Hankland wrote:
> > On Mon, May 27, 2019 at 6:56 PM Wei Wang wrote:
> >> On 05/23/2019 06:23 AM, Eric Hankland wrote:
> >>> - Add a VCPU ioctl that can control which events the gues
On Mon, May 27, 2019 at 6:56 PM Wei Wang wrote:
>
> On 05/23/2019 06:23 AM, Eric Hankland wrote:
> > - Add a VCPU ioctl that can control which events the guest can monitor.
> >
> > Signed-off-by: ehankland
> > ---
> > Some events can provide a guest with i
- Add a VCPU ioctl that can control which events the guest can monitor.
Signed-off-by: ehankland
---
Some events can provide a guest with information about other guests or the
host (e.g. L3 cache stats); providing the capability to restrict access
to a "safe" set of events would limit the potenti
ioctl that sets an event whitelist.
If the guest attempts to program a counter for any unwhitelisted event,
the kernel counter won't be created, so any RDPMC/RDMSR will
show 0 instances of that event.
Signed-off-by: Eric Hankland
---
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/
17 matches
Mail list logo
