[libvirt] Does the proposed solution belong in KVM input devices?
qemu-discuss doesn't seem the best place to reach the devs. 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?
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.
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?
What exactly are you trying to implement. Something similar to the chrome plug-in but for the whole virtual machine? I would imagine that would be best either in the viewer software (e.g. virt-viewer, spicy, etc.), most probably implementing new one that takes care about only sending the events with preset dwell and gap times. In the VM itself that would be probably some type of keyboard, but that sounds more related to the hypervisor level and I imagine that could be done as a special type of keyboard. But a) I'm not sure if that would cover all input from all clients and b) I have no idea what's QEMU community's view on this. I'm sure, however, that if the person sending patches for such feature is able to commit to maintaining the code, then they will be pretty inclusive. Just my $.02 Martin
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 2016-03-16 14:18, Martin Kletzander wrote:
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.
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?
What exactly are you trying to implement. Something similar to the chrome plug-in but for the whole virtual machine?
Yes :)
I would imagine that would be best either in the viewer software (e.g. virt-viewer, spicy, etc.), most probably implementing new one that takes care about only sending the events with preset dwell and gap times.
Is it a matter of changes made at the SPICE level vs QEMU? The former sounds good. Though it should be implemented in a way to make it impossible for a SPICE server in a malicious guest to figure out the original input timing.
In the VM itself that would be probably some type of keyboard, but that sounds more related to the hypervisor level and I imagine that could be done as a special type of keyboard. But a) I'm not sure if that would cover all input from all clients and b) I have no idea what's QEMU community's view on this. I'm sure, however, that if the person sending patches for such feature is able to commit to maintaining the code, then they will be pretty inclusive.
Just my $.02 Martin
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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. Regards, Daniel -- |: 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 :|
participants (3)
-
bancfc＠openmailbox.org -
Daniel P. Berrange -
Martin Kletzander