Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190516/c9186648/attachment-0001.sig>