From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MjHP8-000753-Oq for qemu-devel@nongnu.org; Thu, 03 Sep 2009 14:51:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjHP4-00071N-QN for qemu-devel@nongnu.org; Thu, 03 Sep 2009 14:51:30 -0400 Received: from [199.232.76.173] (port=41189 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjHP4-00071B-HA for qemu-devel@nongnu.org; Thu, 03 Sep 2009 14:51:26 -0400 Received: from mail-ew0-f223.google.com ([209.85.219.223]:50252) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MjHP3-0008C2-S0 for qemu-devel@nongnu.org; Thu, 03 Sep 2009 14:51:26 -0400 Received: by ewy23 with SMTP id 23so211145ewy.8 for ; Thu, 03 Sep 2009 11:51:24 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090903170931.1e7d5772@bud-laptop> References: <20090831180825.6ed2ea55@bud-laptop> <20090901234716.GB1321@shareable.org> <20090903170931.1e7d5772@bud-laptop> From: Blue Swirl Date: Thu, 3 Sep 2009 21:51:01 +0300 Message-ID: Subject: Re: [Qemu-devel] QEMU as a "virtual smart card"? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Bud P. Bruegger" Cc: qemu-devel@nongnu.org, John Forrester On Thu, Sep 3, 2009 at 6:09 PM, Bud P. Bruegger wrote: > On Wed, 2 Sep 2009 17:58:18 +0300 > Blue Swirl wrote: > >> On Wed, Sep 2, 2009 at 2:47 AM, Jamie Lokier >> wrote: >> > 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. =C2=A0It's >> > not completely simple, but it's far from secure. >> >> For additional complexity, the CPU registers, memory, instruction set >> and I/O could be encrypted but there is still a problem: where to >> store the keys. The keys could be handled by another host process, >> which could also try to attest that no debugger is attached (at least >> on that level of virtualization). Performance would suck of course and >> the attestation process could be fooled. > > First of all thanks to everyone for the replies and advice. > > As for encryption of RAM and processor, wouldn't it be necessary to > decrypt things before using it and that would be visible to the > observer on the host machine? The translator will read (decrypt) the memory one instruction at a time, but the instructions will be thrown away. The translated code in TBs will be plain unencrypted host machine code. Someone could even write a decompiler to reconstruct the unencrypted instructions based on the machine code sequences in TBs. > While surely not bullet proof and impossible to crack, I thought that > there may be other ways of rising the hurdle quite a bit. > > Assume that I wanted to protect a secret algorithm in some C program. > Normally this is compiled into the machine code of a certain processor > and there are standard tools (disassembler, debugger) that can be used > to figure out what the secret algorithm does. > > A virtual machine has a virtual processor. =C2=A0Assume now that I was to > shuffle around machine instructions both in the processor of the > virtual machine and in the back-end of my c-compiler. =C2=A0I imagine tha= t > it would be possible to automate this process (some refactoring tool?) > and to do some random shuffling. > > At this point, I guess before looking at the code I'd have to create my > own tools (disassembler, debugger) before even starting to look at what > is happening. > > So maybe there would even be some more room to generate a "random > virtual processor" together with a "random C compiler". =C2=A0Kind of lik= e > generating a key pair :-) There's still the translated output. > That would still leave RAM unprotected, I guess... =C2=A0But maybe there > could be a way of adding some "random" RAM/CPU combination with enough > entropy.. RAM could be encrypted, for example MMU (preferably TLB based) could be enhanced to decrypt/encrypt each page with a different key. The CPU would need to see unencrypted data, but not all of it at the same time. > do you think that is a valid idea? You could validate it with something simple, like by modifying a user emulator so that code pages massaged with XOR still execute. Or reverse the bits in a byte, turn the memory upside down so that address 0 is actually (unsigned long)-1, etc. I don't think this makes any sense from guest security point of view, it's still just obscurity. On the other hand, there is a new benefit when considering a hostile guest case: even if the guest could break out from the the VM, the twisted CPU would also see the host memory in a distorted way. And if we perform the distortion twice by running QEMU inside another twisted VM, the guest inside would have to break from a VM twice with no idea of what kind of machine instructions could be executed in the middle VM. Direct bypass to the real world would still be possible, though the guest would still need to reverse both distortions while doing any host memory writes.