On Sun, Mar 12, 2017 at 11:03 PM, Jean-Philippe Ouellet <[email protected]> wrote: > On Sun, Mar 12, 2017 at 11:01 PM, Jean-Philippe Ouellet <[email protected]> wrote: >> If the reason you are trying to put things there is actually to resist >> local forensics (by only storing vm contents in memory), then a better >> solution would be to encrypt the copy-on-write deltas with an >> ephemeral single-boot key which is forgotten on shutdown. > > Of course I mean a different key per boot of each AppVM, not of the host.
There is also a question of where that dm-crypt should live. Main argument in favor of AppVM instead of dom0: - Makes it easy to ensure the key is forgotten on shutdown, as it is only lives in domU memory, whereas in dom0 the cryptsetup mem could theoretically get swapped Main argument in favor of dom0 over AppVM: - If the AppVM is compromised and wishes to persist some incriminating data on disk (or wants to communicate with malicious disk firmware via contents written or something) then it could bypass a crypto layer implemented in the domU kernel. Third option: (my personal favorite) - Do the crypto in a separate VM that just exists for interposing blk devs. - You get dom0-like anti-leak properties, & AppVM-like anti-key-persistence properties - Downside is increased runtime memory overhead and increased per-write latency (and possibly throughput) performance penalty - If this were done in a minimal stubdomain (like based on mirage unikernel), the memory overhead and likely also performance penalty could be largely minimized - If we perform authentication instead of only encryption, then we also have one of the building blocks already in place for untrusted storage domain (as described in qubes arch spec [1]) If you happen to be a student looking for something to do this summer, I would highly encourage you to consider applying for Google Summer of Code [2] to work on this ;) It would be a very welcome contribution, and if you do want to participate in GSoC I would gladly volunteer to be the project mentor for this. [1]: https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf [2]: https://www.qubes-os.org/gsoc/ -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CABQWM_DDTZXk-7s8C9ytZOLyJsiSrGYAtbFM24o7ON_MU_4DMw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
