On reporting CPU flags that provide mitiation (to CVE flaws) as Nova 'traits'
kchamart at redhat.com
Fri May 17 11:07:21 UTC 2019
On Thu, May 16, 2019 at 10:42:47AM -0500, Eric Fried wrote:
> > I've added a link to this thread on the agenda for tomorrow's
> > Security SIG meeting
> This happened . TL;DR: it does more potential good than harm to
> expose these traits ("scheduler roulette is not a security measure"
Thanks for the summary, Eric. I've just read the relevant IRC log
discussion. Thanks to everyone who's chimed in (Jeremey, et al).
> > Others have said this (at least Dan): This seems like something
> > where something other than nova ought to handle it. A host which
> > shouldn't be scheduled to should be disabled (as a service).
> WFM. Scrap strawman.
> Given that it's not considered a security issue, we could expose the
> (low-level, CPU flag) traits so that "other than nova" can use them. If
> we think there's demand.
Okay, so I take it that all the relevant low-level CPU flags (including
things like SSBD, et al) as proposed here can be added to
'os-traits'. And tools _other_ than Nova can consume, if need be.
Correct me if I misparsed.
> > How do people feel about the idea of forming a core group for those
> > two repos that includes placement cores but has additions from nova
> > (Dan, Kashyap and Sean would make good candidates) and other projects
> > that consume them?
I'm fine participating, if I can provide useful input.
More information about the openstack-discuss