On Thursday, April 4, 2019 at 11:05:09 AM UTC, brend...@gmail.com wrote: > On Thursday, April 4, 2019 at 5:10:39 AM UTC-4, donoban wrote: > > On 4/3/19 11:54 PM, jr...@gmail.com wrote: > > > Looking for guidance on best practices for Qubes configuration: > > > given the vulnerabilities that have been reported with > > > Hyperthreading, it would seem to be a no-brainer that it should be > > > disabled, but I don’t see anyone coming right out and saying so. > > > Curious what this group thinks. > > > > If you mean that disabling it could be too drastic solution or the > > risk in real-world conditions is too low, you could be right. > > > > I read a paper about this where the attacker needed a lot of time > > while other VM was running an infinite loop using a SSL key (no real > > world behavior). So probably, in real conditions this is very very > > hard to exploit. > > > > On the other side, Qubes security model and sense of existence is to > > guarantee that some compromised VM can not compromise other VMs or the > > whole system so just disabling could be reasonable too. > > Makes sense to me: Qubes policy is to enforce safer defaults. User can > modify, at their own risk. > > Layperson's thought: perhaps there could be a CPU allocation strategy in Xen > that allocates cores instead of logical CPUs? That may mitigate the security > issue if the workload would benefit from Hyperthreading (aka SMT). > > Whether this is significantly safer than the default logical CPU allocation > w/ hyperthreading really depends upon the CPU cache strategies in effect, > perhaps. E.g. contemporary Intel CPUs (packages?) have three or more levels > of cache and some interesting cache topologies including cross-core caches... > > Some support software-selectable caching strategies as well for parts of the > cache. > > Brendan
would that work, without static allocation? I'd assume Xen regulates time slices, so that there's always a chance that the cache will still contain stuff from activity generated in/by another VM. I guess you could flush that every time, but I'm sure that generates more than a little overhead. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b1efe6ed-bdde-4f1c-94e3-6bf4c4cd9353%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
