From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: Have any ideas about how to detect whether a program is running inside QEMU?
Date: Thu, 06 Jul 2006 19:06:31 -0500 [thread overview]
Message-ID: <pan.2006.07.07.00.06.28.117184@codemonkey.ws> (raw)
In-Reply-To: 20060706204640.GA28903@aplik.cl
On Thu, 06 Jul 2006 16:46:40 -0400, Daniel Serpell wrote:
> Hi!
>
> El Thu, Jul 06, 2006 at 03:18:14PM +0800, James Lau escribio:
>> My program is a utility for internet payment. It takes an important role
>> in the payment process to ensure security. One of the key functions is
>> that the program should detect which machine is paying. So while virtual
>> machine (like QEMU) is present, it can cheat the program. Checking the
>> hard disk model, cpu type, and other hardward informations makes little
>> sense. Because the users or the hackers can easily modify these
>> informations. So I need a QEMU internal checking method that hackers
>> can't easily bypass.
>>
>>
> Well, as others have argued, this is probably worthless.
>
> But there is a way to detect virtual machines under x86, see
> http://invisiblethings.org/papers/redpill.html
This is an utterly silly way of doing this. For starters, it depends on
your OS and where the monitor hides itself. There is no reason the
monitor couldn't choose a lower address (assuming user-mode emulation).
Also, it's totally useless when QEMU is doing full emulation (or if
hardware virtualization is present).
The only general way of doing this is to exploit timing differences
between the host and guest. Pioneer[1] is a good example of this although
it only works on non-VT/SVM systems. If you were exhaustive about timing
all possible exits, you could extend this to a VT/SVM system.
If hardware is available, static or dynamic attestation also addresses
this problem.
[1]
http://portal.acm.org/affiliated/citation.cfm?id=1095810.1095812&coll=ACM&dl=ACM&type=series&idx=1095810&part=Proceedings&WantType=Proceedings&title=ACM%20Symposium%20on%20Operating%20Systems%20Principles&CFID=15151515&CFTOKEN=6184618
Regards,
Anthony Liguori
> But if you run qemu without direct instruction copying, it won't work (and
> qemu will run slower), because qemu will correctly emulate the
> unprivileged instructions.
>
> Daniel.
prev parent reply other threads:[~2006-07-07 0:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-06 5:04 [Qemu-devel] Have any ideas about how to detect whether a program is running inside QEMU? James Lau
2006-07-06 6:48 ` Natalia Portillo
2006-07-06 6:55 ` John R. Hogerhuis
2006-07-06 7:18 ` James Lau
2006-07-06 8:20 ` Kevin F. Quinn
2006-07-06 10:33 ` Jan Marten Simons
2006-07-07 2:12 ` James Lau
2006-07-06 10:56 ` Jamie Lokier
2006-07-06 20:46 ` Daniel Serpell
2006-07-06 23:21 ` Kevin F. Quinn
2006-07-07 8:07 ` G Portokalidis
2006-07-07 20:36 ` [Qemu-devel] " Anthony Liguori
2006-07-07 0:06 ` Anthony Liguori [this message]
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=pan.2006.07.07.00.06.28.117184@codemonkey.ws \
--to=anthony@codemonkey.ws \
--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).