10:21 p.m.
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?
8:18 a.m.
New subject: [libvirt] Does the proposed solution belong in KVM input devices?
On Wed, Mar 16, 2016 at 04:21:23AM +0100, bancfc(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
10:26 a.m.
New subject: [libvirt] Does the proposed solution belong in KVM input devices?
On 2016-03-16 14:18, Martin Kletzander wrote:
On Wed, Mar 16, 2016 at 04:21:23AM +0100, bancfc(a)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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
12:01 p.m.
New subject: [libvirt] Does the proposed solution belong in KVM input devices?
On Wed, Mar 16, 2016 at 04:21:23AM +0100, bancfc(a)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 :|
3160
days inactive
3166
days old
3 comments
3 participants
participants (3)
-
bancfc＠openmailbox.org -
Daniel P. Berrange -
Martin Kletzander