[talk] Embargo/Foundation questions, Intel CPU/speculation bugs
gnn at neville-neil.com
Mon Jun 18 05:24:24 EDT 2018
Comments in line...
On 18 Jun 2018, at 3:59, Isaac (.ike) Levy wrote:
> Hi All,
> I'm sure folks have been tuned in to the fragmented security news of
> the week: Intel and more speculative execution security flaws. (If
> not, check the URL footnotes below).
> With that, questions for list, genuinely looking for some logical
> answers in favor of the NDA/embargo on critical fixes we've seen in
> recent months:
> - What do folks think about these Intel NDA-covered embargo, (or any
> vendor for that matter)?
> The embargoed information really doesn't seem to be doing us all any
> good at all here as users.
> I'd really love to hear any constructive reasons why the NDA's are
> necessary or good for any project developement?! How does this help
> the world?
> - Specific to FreeBSD, and the Foundation: I've been a huge fan of the
> FreeBSD foundation since it's inception. To separate assets from the
> FreeBSD codebase was certainly born in the SCO era, with the the USL
> vs. BSDi era in mind, etc... this part of the mission of the
> Foundation has always made a lot of sense to me- separating legal
> assets from the codebase for the longevity of the codebase itself.
> The Foundation has done some excellent work, from handling donations,
> coordinating conference attendance, project grants, developer hardware
> and donations- and of course supporting the amazing RELENG work as a
> J.O.B. job for Glen Barber (et. al.). This has produced amazing
> things for FreeBSD.
> Yet, what are the *boundaries* of the mission of the FreeBSD
> Does the foundation even facilitate vendor relationships and shepherd
> NDA's for developers, or am I just totally mistaken here?
Indeed we do. In fact one of my first tasks when I joined the FF was to
get a set of NDAs in place and a process by which any FreeBSD developer
could be given access to NDA'd information from various vendors. We
have these types of relationships with several folks including Intel,
ARM, NVidia and others.
> I mean, a while back they were becomming involved with humanitarian
> projects- wonderful stuff, but not what I donate to the FreeBSD
> Foundation for- and certainly quite a deviation from strategically
> shepherding the legalities of NDA's with Intel.
> These days, I see a lot of great press stuff on the Foundation site,
> but I don't see any clear "here is why we help sign NDA's with Intel."
> I can't even find mention of "NDA" on the Foundation site.
It's not something we'd put on the front page. I and others talk about
this frequently at conferences and developer summits. This kind of
stuff often takes time with our lawyer, and so we don't just do it for
everyone. The typical process is that a developer comes to us with a
need and we work with them to get this in place so they get the
information they need.
> Assuming FreeBSD devlopers/Foundation does have NDA with Intel
> (others) for chip documentation, as well as security vulnearabilities:
Chip docs mostly don't need NDAs, although some graphics stuff still
does, the security stuff from the FF side, is handled by Ed Maste and
one or two of our contractors, as well as by members of the community
who are contacted by Secteam. Secteam and SO are the main project folks
handling this stuff.
> For Meltdown/Spectre, well, I don't know if if NDA's were in place at
> the time- but if it was, it didn't seem to help FreeBSD get any
> mitigations out- (even for several weeks past public disclosure).
The biggest challenges here are not NDAs per se, but with hands and
communication. Intel is big, and FreeBSD is not Linux so there are two
challenges there, and we're continuing to work with Intel to get the
right people to talk to at the right time. Of course, in 6 months those
people will change jobs, so, wash rinse repeat. The hands problem is a
serious one since capable volunteer security experts who can even
understand the problems of Spectre are few and far between.
> Frankly, if the FreeBSD Foundation appears to have handled taking on
> the burden of NDA's which enforce embargos on critical security fixes
> to the FreeBSD codebase, why would various fixes be prevented from
> being applied to the codebase by developers not under NDA, (and not in
> the know)? Excepting that this activity could naturally lead Intel
> legal or others to believe that NDA holders are leaking info, is there
> anything which actually prevents fixes from going into the FreeBSD
> codebase from non-NDA committers?
Leaks have two negative side effects. First and foremost they give some
number of potential attackers a window of opportunity, that's why the
industry has coordinated releases of vulnerabilities. Secondly, leaks
lead to distrust and we'd like these folks to trust us, so that we can
have a good working relationship, and get information sooner rather than
> Last question- stance on Intel::
> Aside from the fact that I'm typing this on an Intel CPU, and this
> message has proably only touched Intel CPU's on it's way to your
> eye-balls reading it, why are we treating Intel so special not to hold
> them accountable or even to ask them to provide user manuals and
> documentation for the CPU's we buy from them, particularly in the case
> of security problems with undocumented features?
I'm slightly confused here, the chip manuals are free and available on
their web site, including updated errata. Of course reading them won't
help you in most cases. Turns out a modern CPU is complicated :-) It
would be hilarious to run an ML system against their manuals to try to
find security issues, but I've got other things to do...
More information about the talk