On Wed, May 29, 2019 at 12:49 AM Wei Wang <wei.w.wang@xxxxxxxxx> wrote: > > On 05/29/2019 02:14 AM, Eric Hankland wrote: > > On Mon, May 27, 2019 at 6:56 PM Wei Wang <wei.w.wang@xxxxxxxxx> 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 <ehankland@xxxxxxxxxx> > >>> --- > >>> 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 potential for the PMU to be used > >>> in any side channel attacks. This change introduces a new vcpu 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. > >> The general idea sounds good to me :) > >> > >> For the implementation, I would have the following suggestions: > >> > >> 1) Instead of using a whitelist, it would be better to use a blacklist to > >> forbid the guest from counting any core level information. So by default, > >> kvm maintains a list of those core level events, which are not supported to > >> the guest. > >> > >> The userspace ioctl removes the related events from the blacklist to > >> make them usable by the guest. > >> > >> 2) Use vm ioctl, instead of vcpu ioctl. The blacklist-ed events can be > >> VM wide > >> (unnecessary to make each CPU to maintain the same copy). > >> Accordingly, put the pmu event blacklist into kvm->arch. > >> > >> 3) Returning 1 when the guest tries to set the evetlsel msr to count an > >> event which is on the blacklist. > >> > >> Best, > >> Wei > > Thanks for the feedback. I have a couple concerns with a KVM > > maintained blacklist. First, I'm worried it will be difficult to keep > > such a list up to date and accurate (both coming up with the initial > > list since there are so many events, and updating it whenever any new > > events are published or vulnerabilities are discovered). > > Not sure about "so many" above. I think there should be much > fewer events that may need to be blacklisted. > > For example the event table 19-3 from SDM 19.2 shows hundreds of > events, how many of them would you think that need to be blacklisted? > > > Second, users > > may want to differentiate between whole-socket and sub-socket VMs > > (some events may be fine for the whole-socket case) - keeping a single > > blacklist wouldn't allow for this. > > Why wouldn't? > In any case (e.g. the whole socket dedicated to the single VM) we > want to unlock the blacklisted events, we can have the userspace > (e.g. qemu command line options "+event1, +event2") do ioctl to > have KVM do that. > > Btw, for the L3 cache stats event example, I'm not sure if that could > be an issue if we have "AnyThread=0". I'll double confirm with > someone. > > Best, > Wei > Not sure about "so many" above. I think there should be much > fewer events that may need to be blacklisted. I think you're right that there are not as many events that seem like they could leak info as events that seem like they won't, but I think the work to validate that they definitely don't could be expensive; with a whitelist it's easy to start with a smaller set and incrementally add to it without having to evaluate all the events right away. > > (some events may be fine for the whole-socket case) - keeping a single > > blacklist wouldn't allow for this. > > Why wouldn't? Ah I think I misunderstood your proposal (as an ioctl that would just enable a hardcoded blacklist). Now that I understand, my main objection is just the above (coupled with the trouble of needing to maintain the "default" blacklist). Eric
