Xen,physical partitions, encryption and a sata controller vm

[Mihail Ivanov]

Hello,

As of currently Qubes uses img files for the VM's which I found to be rather dull. First by virtualizing a filesystem 

we are sure to pay some IO bill, second  they are not separately encrypted.(I know the whole FS is encrypted, but that's not my point).

I take it SATA Controller is in Dom0 so we basically use a PV driver in the DomU which Xen

 implements and allows the DomU to write to the physical disk(probably that's how it works for HVM's,

but not for the PV ones, since they get no PCI devices emulated in them).

In the documentation I've read there were plans to use VM for the SATA controllers, yet here in the forum - people say there are no benefits to it. 

Perhaps that's incorrect :) 

Also I am mainly interested in per VM encryption.

To justify myself - imagine you're using your laptop in a cafe and suddenly someone steals it. There goes your security - 

even if you were just using facebook or some other low-security stuff, all your data is stolen as well, in plaintext. 

Encryption just got useless? 

Hence it's completely necessary to have per VM encryption. 

That way if stolen, only the currently unlocked information will be disclosed.

I am willing to do it myself but the question is whether I should use img files or physical partitions?

Does it pose a security risk to use a physical partition with a DomU?

And if it's the second - that probably means we should get an IDE/SATA VM.

If physical I am thinking of perhaps an LVM in Dom0 with LUKS partitions which are unlocked by Dom0 and then passed to Xen(via dm-crypt mappers to unlocked partitions). The downfall here maybe the fact that we are losing a bit of agility - not sure how easily will we get to resize those partitions.(I've done that before, but it's taken as a bit of an ugly procedure and everyone talks about doing backups and how dangerous it is).

To summarize:

As of my point of view - Qubes is currently a huge vault with a sturdy lock and walls, yet once you're inside - you get everything, and that's not secure. There should be multiple doors, with different keys. Also isn't it a shame having IOMMU and using it just for those ethernet controllers :) No sata, no sound, no gpu. 

I am willing to work to implement per VM encryption, but I'd need info regarding said questions.

Best regards

[cprise]

--

Hi...

First, I doubt there is any downside to using a partition although it might be excluded from the Qubes backup utility.

I think Qubes (at least initially) put physical attacks as a lower priority because the physical platforms have very limited potential for improved security. The Qubes physical security model mostly revolves around anti-evil-maid, and the prerequisite for AEM is that you power down your laptop whenever it is threatened or unattended.

OTOH, quite understandably you are hoping (or assuming) to improve physical security when the laptop is running or sleeping. But coldboot attacks can nullify most security measures in this situation.

In order to work, your individually-encrypted vms may have to prompt the user for the key before or while booting. Otherwise, stored keys could be easily read after a coldboot attack.

[Marek Marczykowski-Górecki]

On 04.08.2014 20:01, Mihail Ivanov wrote:
> Hello,
> As of currently Qubes uses img files for the VM's which I found to be
> rather dull. First by virtualizing a filesystem
> we are sure to pay some IO bill, second they are not separately
> encrypted.(I know the whole FS is encrypted, but that's not my point).

File based storage is mostly for achieve overbooking of disk space. So you can
have a bunch of VMs with 10GB limit each and still use only small percent of
that size in reality.
Since device-mapper now supports thin-provisioning, this probably can be
achieved using LVM also. But we haven't done it because:
a) current solution works (and is tested!)
b) with portability in mind (for Qubes Odyssey framework)

> I take it SATA Controller is in Dom0 so we basically use a PV driver in the
> DomU which Xen
> implements and allows the DomU to write to the physical disk(probably
> that's how it works for HVM's,
> but not for the PV ones, since they get no PCI devices emulated in them).
>
> In the documentation I've read there were plans to use VM for the SATA
> controllers, yet here in the forum - people say there are no benefits to
> it.
> Perhaps that's incorrect :)
> Also I am mainly interested in per VM encryption.
>
> To justify myself - imagine you're using your laptop in a cafe and suddenly
> someone steals it. There goes your security -
> even if you were just using facebook or some other low-security stuff, all
> your data is stolen as well, in plaintext.
> Encryption just got useless?
> Hence it's completely necessary to have per VM encryption.
> That way if stolen, only the currently unlocked information will be
> disclosed.

I understand your point. To make this really secure you need to ensure few things:
- you enter (per-VM) password during VM startup, most likely different
password for different VM
- you wipe password from memory (and disk? think about swap) after VM shutdown

Also I think it would be easiest to implement this inside of VM. Simply
encrypt /dev/xvdb (/rw) partition there and add some GUI prompt during VM
startup (GUI, because you don't have convenient access for VM console). Take a
look at /usr/lib/qubes/init/misc-post.sh.

> I am willing to do it myself but the question is whether I should use img
> files or physical partitions?
>
> Does it pose a security risk to use a physical partition with a DomU?
>
> And if it's the second - that probably means we should get an IDE/SATA VM.
>
> If physical I am thinking of perhaps an LVM in Dom0 with LUKS partitions
> which are unlocked by Dom0 and then passed to Xen(via dm-crypt mappers to
> unlocked partitions). The downfall here maybe the fact that we are losing a
> bit of agility - not sure how easily will we get to resize those
> partitions.(I've done that before, but it's taken as a bit of an ugly
> procedure and everyone talks about doing backups and how dangerous it is).
>
> To summarize:
> As of my point of view - Qubes is currently a huge vault with a sturdy lock
> and walls, yet once you're inside - you get everything, and that's not
> secure. There should be multiple doors, with different keys. Also isn't it
> a shame having IOMMU and using it just for those ethernet controllers :) No
> sata, no sound, no gpu.

Actually those devices are isolated using other mechanism. No VM have direct
access for any dom0 device. We have our super-simple GUI protocol, audio
protocol, etc. Network devices are facing outside world directly, so there is
a lot of sense for isolating them strongly (stronger than sound card for example).

But indeed - if GPU firmware for example got infected, that would be game
over. This infection can't be done from Qubes VM, because VM have no access to
GPU. So atacker needs physical access the machine...

BTW Is anyone aware of any hack for GPU from outside connector
(DP/HDMI/DVI/VGA)? That would be interesting.

Because of this (and other reasons), we are planning to split GUI from dom0 in
Qubes R3, see:
https://wiki.qubes-os.org/ticket/833

This is prerequisite for Storage domain (disk controller in unprivileged
domain) because dom0 needs to be stripped for this (think about dom0 startup).
Note that currently we don't plan to implement Storage domain (at least not in
R3).

>
> I am willing to work to implement per VM encryption, but I'd need info
> regarding said questions.
>
> Best regards
>

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Alex Dubois]

Alex

Couldn't you do storage VM if you boot from USB?

[Marek Marczykowski-Górecki]

You need dom0 filesystem somewhere. But yes, USB boot is one of possible
solutions, although not very convenient one.

[Alex Dubois]

Alex

> On 4 Aug 2014, at 22:25, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:
>
>> On 04.08.2014 23:14, Alex Dubois wrote:
>>> On 4 Aug 2014, at 21:39, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:
>>> This is prerequisite for Storage domain (disk controller in unprivileged
>>> domain) because dom0 needs to be stripped for this (think about dom0 startup).
>>> Note that currently we don't plan to implement Storage domain (at least not in
>>> R3).
>>
>> Couldn't you do storage VM if you boot from USB?
>
> You need dom0 filesystem somewhere. But yes, USB boot is one of possible
> solutions, although not very convenient one.
>

Is the risk really lower than nic or video drivers that it is put so far away?

I had started a similar protocol to the video one with the front-end pushing to a VM that was only encrypting the flow (target was to have a mirageOS vm) and pushing it to a back-end. I dropped the project as I had not enough time.

The compromised VM would have had a hard time forging a stream to attack the back-end.

[Mihail Ivanov]

Hello,

so I take it - passing a physical partition to a DomU isn't insecure?

Also - shouldn't the decryption take place in Dom0 and then pass the unlocked partition to Xen?

(that is when starting the VM from Dom0, the GUI asks for the passwords, unlocks the partition - it has a constant label, when unlocked,

and starts it, therefore Xen will use the unlocked partition).

Afterwards - when the user wants, 

he can delete the key from memory and kill the VM, 

therefore negating cold boot attacks.

I will look into /usr/lib/qubes/init/misc-post.sh later.

As for the Sound.

I perfectly well understand how the Sound works, yet it seems to me you're ignoring the chance that there are exploits for the DSP.

Basically I've read that you say the sound frames are sent to the sound card and nowhere executed as code. Yet, isn't there a chance

that the sound card could be exploited by those frames(recent sound card get more complex, have dedicated CPU's,etc).

Now about the GPU:

I am thinking the VM which owns the GPU can flash it with whatever it wants.

Or that is probably the case for most GPU's anyway.

So a friend of mine was wondering if we can do the following:

Use a GPU switch VM, basically it should do this->

PC has two gpus - g1,g2. g1 always stays in Dom0

g2 can move around and on boot is not in Dom0

So we decide we want g2 in DomU1 =>

g2 is passwed to GPU Switch VM,

We deny the GPU access to our memory

and check it's bios.

After that - if it has changed, we flash it anew.

Afterwords we clean-up it's memory.

The GPU Switch VM can be read only, 

so it will be restored to the same state each time the GPU must be checked.

When we are done - the GPU is clean and ready to be passed to DomU1.

Can you comment on this solution?

Now there's another one which I propose:

To avoid the chance of GPU memory corruption and GPU Bios corruption,

why not pass the IGP around? Most desktops and laptops have

 IGP's which use the system memory and have no bios.

I've read in Xen's ml it's possible to pass the IGP around.

And about the USB:

Basically I think we need USB PV as well, I know there's some beta stuff, and maybe if I get some free time

I will look into it, as it's a crucial part as well. 

I think it's a necessity to boot from USB, otherwise one needs TPM and vPro if possible(although I've read the articles on qubes's site and don't really trust TXT).

Hence getting a storage VM should be easier.

[Marek Marczykowski-Górecki]

On 04.08.2014 23:58, Mihail Ivanov wrote:
> Hello,
> so I take it - passing a physical partition to a DomU isn't insecure?

In both cases we trust xen-blkback driver, no difference here.
You need to ensure that those partitions will never get parsed in dom0. For
file-baked disk we have custom udev rules for that.

> Also - shouldn't the decryption take place in Dom0 and then pass the
> unlocked partition to Xen?
> (that is when starting the VM from Dom0, the GUI asks for the passwords,
> unlocks the partition - it has a constant label, when unlocked,
> and starts it, therefore Xen will use the unlocked partition).

Actually Xen (as a hypervisor) do not handle disks in any special way. It only
provides communication interface (shared memory), so backend domain (dom0
currently) can provide disk access for frontend domain (the VM).

Regarding place of decryption - it makes no big difference. In both cases VM
have access to the data (own private.img). If encryption takes place in VM,
the VM have access to the encryption password/key. But this key gives access
to... this VM private.img, nothing more. Unless you use the same/similar
password for other things...

To minimize amount of passwords to remember, you can use some password manager
- decrypt password vault only for a short time to start the VM, and then wipe
its memory. It even can be automated somehow ("enter master password to start
the VM").

> Afterwards - when the user wants,
> he can delete the key from memory and kill the VM,
> therefore negating cold boot attacks.
>
> I will look into /usr/lib/qubes/init/misc-post.sh later.
>
> As for the Sound.
> I perfectly well understand how the Sound works, yet it seems to me you're
> ignoring the chance that there are exploits for the DSP.
> Basically I've read that you say the sound frames are sent to the sound
> card and nowhere executed as code. Yet, isn't there a chance
> that the sound card could be exploited by those frames(recent sound card
> get more complex, have dedicated CPU's,etc).

I would classify this type of attack as "Very Unlikely(TM)". Somewhere near
"sound card exploited by playing specially crafted sound to the mic".

> Now about the GPU:
> I am thinking the VM which owns the GPU can flash it with whatever it wants.
> Or that is probably the case for most GPU's anyway.

Yes, except that in Qubes (at least for now), no VM have direct access to the GPU.

> So a friend of mine was wondering if we can do the following:
>
> Use a GPU switch VM, basically it should do this->
> PC has two gpus - g1,g2. g1 always stays in Dom0
> g2 can move around and on boot is not in Dom0
>
> So we decide we want g2 in DomU1 =>
> g2 is passwed to GPU Switch VM,
> We deny the GPU access to our memory
> and check it's bios.
> After that - if it has changed, we flash it anew.
> Afterwords we clean-up it's memory.
> The GPU Switch VM can be read only,
> so it will be restored to the same state each time the GPU must be checked.
> When we are done - the GPU is clean and ready to be passed to DomU1.
>
> Can you comment on this solution?

I don't know if this is technically possible (especially checking if GPU
firmware hasn't changed). Perhaps we can simply flash the GPU every time? I
wonder how many firmware flash GPU can sustain...

But the idea sounds right.

>
> Now there's another one which I propose:
> To avoid the chance of GPU memory corruption and GPU Bios corruption,
> why not pass the IGP around? Most desktops and laptops have
> IGP's which use the system memory and have no bios.
> I've read in Xen's ml it's possible to pass the IGP around.

I'm not sure if the fact that IGP is simpler is enough. But surely reduce
attack surface.

> And about the USB:
>
> Basically I think we need USB PV as well, I know there's some beta stuff,
> and maybe if I get some free time
> I will look into it, as it's a crucial part as well.

Yes, we need USB PV. This is a long story, but in short: there are a few
implementations, every have some pros and cons, including stability ("not
working at all, panic every 5 min ;)"), OS support ("frontend driver only for
windows") etc.
I plan to write some separate mail/wiki page about it (current state and
possibilities). But probably will have time for this only after final R2 release.

> I think it's a necessity to boot from USB, otherwise one needs TPM and vPro
> if possible(although I've read the articles on qubes's site and don't
> really trust TXT).

USB boot doesn't make TPM / TXT unnecessary. You still want some way to verify
(or exclude from TCB) BIOS for example.

> Hence getting a storage VM should be easier.

Please, don't top-post.

[Axon]

Marek Marczykowski-Górecki:

Any idea how this could be made practical for those of us with 60+ VMs?

I see a few initial possibilities:

1. Find some way to automate the process of entering the per-VM
passphrases. But the risk is that this automated process will also allow
the person who steals your laptop to gain access to the encrypted VMs.
(Perhaps a timeout could be implemented which re-prompts for the master
passphrase at a user-defined interval in order to allow the user to
choose how he or she wants to balance convenience and sedcurity).

2. Use a passphrase manager. (If the GUI prompt is in dom0, the
passphrase manager will have to be in dom0. If it's in a VM, it can of
course be in any VM.) Of course, the passphrase manager can't be left
open and accessible all the time, since then it'll be accessible to the
person who steals your laptop, so you'll have to either use a manager
like KeePassX, which allows the user to set a timed lockout, or remember
to close it after you unlock your VMs. (Of course, the passphrase
manager's database file should itself be encrypted if it would be
accessible to the thief.)

3. Make the VM encryption optional and choose to individually encrypt
only a manageable number of important VMs. (But this suggests that there
should still be FDE in order to protect all the other VMs.)

Final thought: For most regular Qubes users, including myself, the most
important VM is the "vault" VM (or equivalent), which is necessarily
running all the time because it contains the passphrase manager (which
is running in that VM) which is used to copy/paste passphrases into
everything else. So, the odds are that this VM would already be
decrypted when the thief steals the laptop. OTOH, perhaps once per-VM
encryption is implemented, users will change their behavior in this
regard, e.g., shutting down their important VMs when they spot a shady
character nearby. ;)

[Axon]

Marek Marczykowski-Górecki:

> On 04.08.2014 23:58, Mihail Ivanov wrote:
>> Hello,
>> so I take it - passing a physical partition to a DomU isn't insecure?
>
> In both cases we trust xen-blkback driver, no difference here.
> You need to ensure that those partitions will never get parsed in dom0. For
> file-baked disk we have custom udev rules for that.
>
>> Also - shouldn't the decryption take place in Dom0 and then pass the
>> unlocked partition to Xen?
>> (that is when starting the VM from Dom0, the GUI asks for the passwords,
>> unlocks the partition - it has a constant label, when unlocked,
>> and starts it, therefore Xen will use the unlocked partition).
>
> Actually Xen (as a hypervisor) do not handle disks in any special way. It only
> provides communication interface (shared memory), so backend domain (dom0
> currently) can provide disk access for frontend domain (the VM).
>
> Regarding place of decryption - it makes no big difference. In both cases VM
> have access to the data (own private.img). If encryption takes place in VM,
> the VM have access to the encryption password/key. But this key gives access
> to... this VM private.img, nothing more. Unless you use the same/similar
> password for other things...
>
> To minimize amount of passwords to remember, you can use some password manager
> - decrypt password vault only for a short time to start the VM, and then wipe
> its memory. It even can be automated somehow ("enter master password to start
> the VM").
>

You're faster than I, Marek. :)

[Franz]

On Mon, Aug 4, 2014 at 8:16 PM, Axon <ax...@openmailbox.org> wrote:

Marek Marczykowski-Górecki:

If someone suddenly steals my computer, isn't automatic screen lock enough to prevent access to my open VMs? The thief will need time to run with the computer to a safe place and in the mean time the screen will lock. He will also be obliged to close the lid to properly hold the laptop while running and this also locks the screen. I will probably be able to close the lid myself, offering the laptop requested with a gun. After all, isn't closing the lid a form of kindness?

Certainly the thief cannot image that I'm using a sophisticated OS with an open vault VM to keep passwords. Most people just use the same password for everything.

Much more serious is the case of falling in a trap for passwords. For example a retired CIA agent spending time on his yacht at the San Blas islands (Panama) was approched by a thief, also yacht owner, who made an invitation to drink something, chat etc. After the thief got enough information that the CIA agent was totally alone, kidnapped him, moved the yacht to a totally isolated area (some islands are inhabited by natives) and tortured the CIA agent to get his bank account passwords, then, satisfied killed the CIA agent and sink his yacht. The Panama police got the thief much later casually trying to cross the Darien Jungle from Panama to Colombia with $300000, fake documents and a booklet filled with names, bank accounts and passwords of other yacht owners that disappeared in previous years.  I was a guest of another yacht owner there, who also was invited for a drink by the thief, but declined.

[HW42]

Am Mon, 04 Aug 2014 23:16:39 +0000
schrieb Axon <ax...@openmailbox.org>:

4.
Use only FDE but use some Bluetooh/NFC/What-Ever-Dongle which is in your
pocket and a script which shutdowns/hibernate/lock your computer when
removed. The communication part can be in a mostly untrusted VM (since
it's talks via Radio to the World). This VM has only the right to
trigger the shutdown via Qubes-RPC. This opens the possibility of a
DOS-attack - which is probably acceptable.

[cprise]

The theif, or whoever he deals with, may be imagining "the more sophisticated the user, the better, as long as a coldboot attack will still work" -- and he knows the laptop may be worth 10-50X times more when its still running or sleeping. A coldboot attack is just the sort that will work on an encrypted-disk system with a locked screen, and unfortunately it works well. AEM gives you a decent chance of foiling a data breech from physical attack, but the laptop has to be powered down for it to work (i.e. you have to prevent the possibility of coldboot attack in the first place).

I like Axon's idea of a 'keeppass for Qubes volumes'... The user types in the same master passphrase to decrypt the disk passphrase database each time a vm is started, and then a Qubes routine sends the correct passphrases to each starting vm. The master passphrase could stay in effect for X number of seconds, allowing the user time to efficiently start Y number of vms.

[Wojciech Zygmunt Porczyk]

On Mon, Aug 04, 2014 at 10:39:32PM +0200, Marek Marczykowski-Górecki wrote:
> BTW Is anyone aware of any hack for GPU from outside connector
> (DP/HDMI/DVI/VGA)? That would be interesting.

Display connectors have an attack surface, there is I2C link inside all
of them since VGA that is used to negotiate resolution. People tend to
hack displays and not controllers, because more fun.


--
regards
WZJP

[Joanna Rutkowska]

What do you mean by a "display"? A monitor? And by "controller"? A GPU?

j.

[Joanna Rutkowska]

AEM, if using TXT-based boot, can protect against Cold Boot attacks
pretty well[*], because a TXT-compatible BIOS would refuse to unlock
access to DRAM if the system was shutdown un-cleanly (which would have
to be the case in this scenario).

[*] Unless we consider a physical removal of DRAM dies and plugging them
into a standalone DRAM reader, which however could be prevented by
having a laptop with soldered DRAM dies.

> I like Axon's idea of a 'keeppass for Qubes volumes'... The user types in the
> same master passphrase to decrypt the disk passphrase database each time a vm is
> started, and then a Qubes routine sends the correct passphrases to each starting
> vm. The master passphrase could stay in effect for X number of seconds, allowing
> the user time to efficiently start Y number of vms.
>
>

Sounds ok.

joanna.

[Joanna Rutkowska]

On 08/05/14 00:47, Marek Marczykowski-Górecki wrote:
>> > So a friend of mine was wondering if we can do the following:
>> >
>> > Use a GPU switch VM, basically it should do this->
>> > PC has two gpus - g1,g2. g1 always stays in Dom0
>> > g2 can move around and on boot is not in Dom0
>> >
>> > So we decide we want g2 in DomU1 =>
>> > g2 is passwed to GPU Switch VM,
>> > We deny the GPU access to our memory
>> > and check it's bios.
>> > After that - if it has changed, we flash it anew.
>> > Afterwords we clean-up it's memory.
>> > The GPU Switch VM can be read only,
>> > so it will be restored to the same state each time the GPU must be checked.
>> > When we are done - the GPU is clean and ready to be passed to DomU1.
>> >
>> > Can you comment on this solution?
> I don't know if this is technically possible (especially checking if GPU
> firmware hasn't changed). Perhaps we can simply flash the GPU every time? I
> wonder how many firmware flash GPU can sustain...
>
> But the idea sounds right.
>

Not quite -- if we worry that the GPU firmware got infected, then we no
longer can trust the GPU to reliably reflash the firmware anymore.

>> >
>> > Now there's another one which I propose:
>> > To avoid the chance of GPU memory corruption and GPU Bios corruption,
>> > why not pass the IGP around? Most desktops and laptops have
>> > IGP's which use the system memory and have no bios.
>> > I've read in Xen's ml it's possible to pass the IGP around.
> I'm not sure if the fact that IGP is simpler is enough. But surely reduce
> attack surface.
>

The magic phrases you use: "GPU memory corruption" and "BIOS memory
corruption" don't make much sense. More correctly we should say: GPU
state compromise, GPU firmware compromise, BIOS SPI flash compromise,
SMM memory compromise. The mere fact whether IGP uses "system memory" or
"GPU memory" is not something that could be taken as a proof of its
resistance to compromises. In fact a discreet GPU also "uses" system
memory, but again, this is not relevant.

What is relevant: can we reliably restart GPU state via bus reset, and
can we be sure its firmware cannot be reflashed by a VM which we give
full access to it? Indeed, I think that for Intel integrated GPUs it is
reasonable to assume that, but nor for the reasons you mentioned.

joanna.

[cprise]

That is good to know, and I can imagine it tripping up some attackers
who try to use the stolen system as the reader.

> [*] Unless we consider a physical removal of DRAM dies and plugging them
> into a standalone DRAM reader, which however could be prevented by
> having a laptop with soldered DRAM dies.
>
>> I like Axon's idea of a 'keeppass for Qubes volumes'... The user types in the
>> same master passphrase to decrypt the disk passphrase database each time a vm is
>> started, and then a Qubes routine sends the correct passphrases to each starting
>> vm. The master passphrase could stay in effect for X number of seconds, allowing
>> the user time to efficiently start Y number of vms.
>>
>>
> Sounds ok.
>
> joanna.

Of course, there are alternatives to this which have been discussed on
the Qubes lists involving sensors or hibernation or development of some
form of encrypted sleep mode.

[cprise]

Dom0 would be the best place to put an automatic key database for vm
volumes, because dom0 is what automates other aspects of vm operation
and the keys have no significance outside of that scope. Dom0 already
manages other aspects of disk and console security as well. OTOH, the
data kept in the vault vm pertains to all sorts of things from the
user's life; probably most of it is not Qubes-specific or even
pertaining to running a PC in general. Under Mihail's threat model, the
vault should not be left running if its individually encrypted; if its
not encrypted then it wouldn't matter.

Having it in dom0 would mean you could easily implement a timeout +
automatic erasure from memory without impacting the user's other activities.

[Alex Dubois]

Alex

True, for key management.

Also while prototyping I had doubts on the benefits to have the implementation of the crypto in an encryption-proxyVM rather than on Dom0. The original idea was to replicate the Qubes video drivers idea. Also in the video case the security was coming from going back to stripping all meta-data and going back to raw pixels/colors. In the storage drivers, my initial assumption was that the complexity (and risk) was in the boxing of the blocks to be stored by Dom0 file system+drivers+..., but as no end user looks at the data, scrambling on the way was the goal to limit attack surface.

>
> --
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-devel.
> For more options, visit https://groups.google.com/d/optout.

[Andrew B]

I really like this idea.

I already use a poor approximation of this, by simply creating a LUKS-encrypted loopback device in some AppVMs (e.g. 'vault', 'bitcoin-keys') and storing all relevant data within that image. Of course this is kludgy, inconvenient, and has risks, like keyloggers inside the AppVM leaking passphrases or key material over a covert channel (or directly over the network for those AppVMs which are connected to a NetVM).

IMO it would be best to have optional, configurable, per-AppVM private.img LUKS FDE managed either in Dom0 directly, or in a dedicated networkless AppVM with a brain-dead "read 32 bytes and pass to cryptsetup" key communication protocol with Dom0. As I see it there should be two types of private.img FDE: (1) 'automatic' - decrypt each 'automatic' AppVM with the same master password (but different LUKS master key and salt, obviously), with auto-erasure after configurable timeout, and (2) 'individual' - for the most sensitive VMs, use a distinct passphrase which is erased immediately after entry. The reason I think (2) is a good idea is that the master passphrase for (1) will be entered often, providing more opportunity for an attacker to observe passphrase entry. So long as you only decrypt 'individual'-encrypted AppVMs in a SCIF [;)], those 'individual' AppVMs will still be protected. At the same time, the use of one master passphrase for 'automatic' and less-sensitive AppVMs mean
s it's more practical for a user to use truly unique passphrases where it matters.

I don't see a ticket for this in trac, yet. Marek, Joanna, do you have any objections? It doesn't seem to be super difficult to implement. If you guys are understandably too busy with other stuff I might take a crack at integrating this functionality into Qubes Manager in a few weeks, when I get some more free time.

Andrew

[Mihail Ivanov]

I agree my terminology in this case was somehow off. Yet what I meant to say was

that CPU's nowadays are meant with virtualization in mind, hence the IOMMU for the system memory,

(unlike GPU's - which I've read also have internal IOMMU but are a mess,

 since they were never created for virtualization) therefore limiting the access of 

the internal GPU and making it unable for it to persist a bad state.

 

What is relevant: can we reliably restart GPU state via bus reset, and
can we be sure its firmware cannot be reflashed by a VM which we give
full access to it? Indeed, I think that for Intel integrated GPUs it is
reasonable to assume that, but nor for the reasons you mentioned.

joanna.

Also there's this project called OpenRadeonBion(self-explanatory name), 

so I wonder - if we flash a custom bios, can we prevent overwrites?

 

About turning on and off a VGA, what comes to my mind is nVidia Optimus.

Since nVidia provides no native support for Optimus on Linux,

most Linux users with nVidia in their laptops  do the following:

use a deamon called bumblebeed =>

it turns off the discrete nvidia GPU upon starting the laptop

(using the bbswitch driver or vga_switcheroo (compiled into the kernel))

and a launcher(primusrun, optirun,etc) basically tells the daemon to ask the driver to turn on the GPU, 

load its driver and starts a second X server

afterwards a graphic intensive app can be started with the second X server, thus using the discrete GPU, 

it's frames are then shown in the first X server using a bridge(ex. VirtualGL).

Afterwards if not needed, the second X server is killed, the drivers unloaded and the VGA is turned off.

It's still shown by lspci through, so it's practically in a different power state.

Now about the per VM crypto,

It seems there are the following options storage options(correct me if I am wrong):

NFS, raw images, cow images, LVM's, raw partitions.

I take it we are currently using CoW images.

Is there any advantage to them besides the ability to use an OS other than Linux in Dom0,

and the somehow general agility?

From what I've read it seems LVM should be faster but I can't tell by how much.

As for the CoW images I've read they have encryption, but

it's poorly implemented, therefore LUKS will be necessary.

So my question is - should we map our CoW image as a block device in Dom0, 

afterwards unlock it with cryptsetup

and pass the mapped device to our DomU

(but we must not parse that device, is that easily done? perhaps with udev rules as Marek has proposed)? 

Is that a good enough plan?

This way - we don't care what is in DomU, it needs not know about being encrypted, nor it needs be Linux.

Also we can easily lock/unlock all the storage from Dom0.

Through I am not sure if this will work well with dynamic resizes which kinda defeats CoW's idea...

Please comment and correct my solution if necessary.

Best regards,

Mihail