Hi, Preamble: I'm still not convinced the benefits of the "Live amnesic host OS + Tor routing VM + desktop VM" approach are worth the energy we would need to move Tails to this model, but I do find it interesting to go on a bit with the thought experiment, and to explore the limits of this idea.
Maxim Kammerer wrote (26 Mar 2012 16:12:41 GMT) : > On Mon, Mar 26, 2012 at 00:52, intrigeri <[email protected]> wrote: >> I'm curious about what resources proved to be limiting during your >> experiments, and what "too demanding" means in your usecases. > Well, Intel VT / AMD-V virtualization extensions are rarely > available on laptops, and without these extensions (accessible, > e.g., via KVM), running a virtualized instance is extremely slow In my experience, a 7 year old laptop with no VT extensions runs quite comfortably a full Debian desktop inside a VirtualBox virtual machine. Obviously, you don't get the entire power of your bare metal CPU, but you don't lose that much either, and I would certainly don't feel the end result to be anything like "extremely slow". On the other hand, my experience with QEMU clearly matches the "extremely slow" results. Maybe your conclusions on VM speed are simply too tightly bound to QEMU? > There are also RAM requirements — how much do you allocate? > This needs to be decided in advance, regardless of how much memory > the user needs for performing the task in the VM. In the scenario this thread is about, I don't think it's that hard to find a way of splitting the memory that allows the user to perform their task, without being all too wasteful: * the host system's memory needs are not likely to vary much, are they? * the Tor routing VM memory needs are not likely to vary much, either * the Desktop VM gets what's left Obviously, this gets much harder for applications VM. >> I would be happy to learn why you consider this is pointless. > For tasks like abstracting network interfaces and other hardware, > the user can run everything in a VM by themselves — why force it > on everyone? These abstractions are probably the only reason why I think this approach would somehow make sense for Tails needs (even if I don't know if we will go this way in the end). This is hardly a technical question. It's obvious to me how the way you ask it, and the way I am answering, say much about how Tails and Liberté Linux differ in their approach of non-technical matters, in the ways we think our relationship to users. Let's catch this opportunity to explain my take on this a bit, and hopefully understand each other better. Note that I don't care about convincing anyone here :) So, why would it make sense to pre-configure, for everyone, the technical tools that get these abstractions up and running? Because Tails is about building a common pre-configured system that tries to address certain common needs, for anyone who happens to share these needs. (We certainly value user {self-,}education very much, as I think the recent efforts put into reorganizing and writing Tails documentation clearly displays: learning some amount of technical stuff is a must to make ones own security decisions properly. But I absolutely don't think that "learning how to choose, install and configure virtualization software, and how to setup a Tails or Liberté VM in there" belongs to the kind of knowledge that empowers people to make their own security decisions properly. I'd rather see Tails users learn things more useful than this.) Because, while people can run Tails in a VM by themselves already, doing this certainly does not give them the same benefits as an integrated, pre-configured "Live amnesic host OS + Tor routing VM + desktop VM" Tails would: * In the first case, they have to trust _their host system_ to not steal information, and to not leak anything to disk, willingly or not. * In the second case, they don't need to setup and configure that host system, because we do. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
