On reporting CPU flags that provide mitiation (to CVE flaws) as Nova 'traits'

Kashyap Chamarthy 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 [1]. TL;DR: it does more potential good than harm to
> expose these traits ("scheduler roulette is not a security measure"
> --fungi).

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[2][3] 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.

> ++
> efried
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2019-05-16.log.html#t2019-05-16T15:06:24

[2] https://review.opendev.org/#/c/655193/4/os_traits/hw/cpu/x86.py
[3] https://review.opendev.org/#/c/655193/4/os_traits/hw/cpu/amd.py


More information about the openstack-discuss mailing list