On 07/03/2019 01:46 AM, Eric Hankland wrote:
Sounds good to me.
If you don't have any more comments I'll send out the next version
with all the requested changes.
No more so far. I'll see your new version.
Best,
Wei
> 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
On 06/25/2019 08:32 AM, Eric Hankland wrote:
Thanks for your feedback - I'll send out an updated version
> incorporating your comments shortly (assuming you don't have more
> after this).
Actually I have another thing to discuss:
probably we could consider to make this filter list white/black
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
> 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
Eric Hankland writes:
>
> +int kvm_vcpu_ioctl_set_pmu_whitelist(struct kvm_vcpu *vcpu,
> +struct kvm_pmu_whitelist __user *whtlst)
> +{
> + struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
> + struct kvm_pmu_whitelist *old = pmu->whitelist;
> + struct
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 information about other guests or the
host (e.g. L3 cache stats); providing the capability to restrict access
On 06/14/2019 01:43 AM, Eric Hankland wrote:
Since we aren't using QEMU, I don't have those patches ready yet, but
I can work on them if you want to review them at the same time as this
patch. The architectural events (minus the LLC events) are probably a
reasonable starting point for the
Since we aren't using QEMU, I don't have those patches ready yet, but
I can work on them if you want to review them at the same time as this
patch. The architectural events (minus the LLC events) are probably a
reasonable starting point for the whitelist.
Eric
On Thu, Jun 6, 2019 at 12:31 AM
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 are any better examples.
I asked and it sounds like we are treating all events as potentially
insecure
>> 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
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
On 06/04/2019 01:30 AM, Eric Hankland wrote:
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
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
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
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:
> On 05/23/2019 06:23 AM, Eric
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:
On 05/23/2019 06:23 AM, Eric Hankland wrote:
- Add a VCPU ioctl that can control which events the guest
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 guest can monitor.
> >>>
> >>>
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 guest can monitor.
Signed-off-by: ehankland
---
Some events can provide a guest with information
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 information about other guests or the
> >
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 information about other guests or the
host (e.g. L3 cache stats); providing the capability to restrict access
- 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
22 matches
Mail list logo
