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.
ACK.
> 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
--
/kashyap
More information about the openstack-discuss
mailing list