[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Does the proposed solution belong in KVM input devices?

On Wed, Mar 16, 2016 at 04:21:23AM +0100, bancfc openmailbox org wrote:
> qemu-discuss doesn't seem the best place to reach the devs.

You should have used qemu-devel really - few devs look at qemu-discuss
since that's for user self-support.

> I saw most of the work on KVM input devices was done by Gerd Hoffman and Dan
> Berrange. Dan do you think the QEMU virtual keyboard is the right place for
> a solution similar to the one described below?
> https://paul.reviews/behavioral-profiling-the-password-you-cant-change/
> Would this be considered feature creep and best implemented in its own
> program?

It is pretty hard to say one way or the other. On the one hand this is a
specific behavioural policy, which argues towards having it done by the
management application (ie the SPICE/VNC client). On the other hand though
QEMU has 6 different display technologies (SDL, SDL2, Cocoa, GTK, VNC
and SPICE), and I can see the random input delay feature being desirable
for users regardless of which display technology they use.

Then again, why should only apps running inside QEMU benefit from this
protection. I'd like my firefox instance on my nonvirtualized desktop
to be protected.

So I'd probably ultimately argue that either Xorg/Wayland, or even the
Linux kernel should be where you do the fix to add random delay. Doing
it in the kernel ensures absolutely everything consuming input events
on your workstation is protected.

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]