On 2019-05-16 10:42:47 -0500 (-0500), Eric Fried wrote: [...]
I've added a link to this thread on the agenda for tomorrow's Security SIG meeting
This happened [1]. TL;DR: it does more potential good than harm to expose these traits ("scheduler roulette is not a security measure" --fungi). [...]
To reiterate my position from the SIG meeting, I only really care whether or not processes which need to know about CPU details for enabling modes to cope with these vulnerabilities have access to them (generally so they can drop their own inefficient mitigations when presented with CPU flags which indicate they're unnecessary because the relevant microcode has been installed on the host or the particular chip lacks that design flaw entirely). That is security-relevant. Whether users want to be able to make scheduling choices based on those same flags, and whether the operators of those environments want to grant them the ability to do so, isn't really a security-relevant discussion point. I support providing a means for users to get good performance on secure systems by default. Anyone who wants to knowingly choose less secure systems to gain a performance boost, or to intentionally shuffle specific customer workloads onto less secure parts of their infrastructure is welcome to those features, but I don't consider that to really be a security topic. At that point it's more of a discussion about people making (hopefully well-informed) trade-offs for the sake of performance and efficiency. -- Jeremy Stanley