From: Jamie Lokier <jamie@shareable.org>
To: "Bud P. Bruegger" <bruegger@ancitel.it>
Cc: qemu-devel@nongnu.org, John Forrester <forrester@ancitel.it>
Subject: Re: [Qemu-devel] QEMU as a "virtual smart card"?
Date: Wed, 2 Sep 2009 00:47:16 +0100 [thread overview]
Message-ID: <20090901234716.GB1321@shareable.org> (raw)
In-Reply-To: <20090831180825.6ed2ea55@bud-laptop>
Bud P. Bruegger wrote:
> At least looking naively at QEMU, it seems that its CPU and RAM are
> well protected from the host operating system--in a way to say make it
> practically impossible for some malware to extract the secret key used
> in a virtual machine.
No, the CPU and RAM state inside QEMU is easily read from the host.
Just run a debugger and attach to the running QEMU process. It's not
completely simple, but it's far from secure.
> Is this a valid conception of what QEMU does? How good is the
> isolation of a virtual machine from the host operating system.
The virtual machine is an ordinary process in the host operating
system, so it's contents can be inspected just like any other host
process using debugging tools.
The point of a VM is to make sure things on the VM cannot inspect the
host or anything else running on the host, including other VMs, except
for what it's given access to... It doesn't isolate the other way around.
However, you can still isolate using ordinary multi-user host process
protections, so unprivileged user A cannot access user B's VMs. VMs
are no different from other processes in this respect.
> We are also interested in the isolation of input devices, in
> particularly the keyboard as to prevent PIN sniffing. My "naive"
> impression is that key logging for a PS/2 keyboard is probably more
> difficult than with a USB keyboard. Is there any thruth to my
> misconception?
None. Key logging for PS/2 is easier than USB using radio antennae or
by inspecting the protocol or by looking at system calls relaying the
data, or even by looking at kernel memory buffers.
Maybe you meant that keylogging is more difficult for USB than PS/2?
> Finally one last question questions:
>
> * Is there any way of getting exclusive access to an USB pen drive
> from a virtual machine, preventing the host operating system to say take
> an image of the content?
Yes against casually reading it, but no against a determined hacker,
who can examine everything which happens on the virtual machine,
including all I/O, if they have access to the host and suitable
permissions to access the VM's host process.
-- Jamie
next prev parent reply other threads:[~2009-09-01 23:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-31 16:08 [Qemu-devel] QEMU as a "virtual smart card"? Bud P. Bruegger
2009-09-01 22:27 ` Laurent Vivier
2009-09-01 23:47 ` Jamie Lokier [this message]
2009-09-02 14:58 ` Blue Swirl
2009-09-03 15:09 ` Bud P. Bruegger
2009-09-03 18:51 ` Blue Swirl
2009-09-04 12:08 ` Paul Brook
2009-09-04 13:12 ` Lennart Sorensen
2009-09-04 13:40 ` Bud P. Bruegger
2009-09-05 2:21 ` Jamie Lokier
2009-09-02 6:58 ` [Qemu-devel] " Paolo Bonzini
2009-09-02 9:17 ` François Revol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090901234716.GB1321@shareable.org \
--to=jamie@shareable.org \
--cc=bruegger@ancitel.it \
--cc=forrester@ancitel.it \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).