[talk] Embargo/Foundation questions, Intel CPU/speculation bugs

Isaac (.ike) Levy ike at blackskyresearch.net
Sun Jun 17 15:59:01 EDT 2018

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 foundation?
Does the foundation even facilitate vendor relationships and shepherd NDA's for developers, or am I just totally mistaken here?
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.

Assuming FreeBSD devlopers/Foundation does have NDA with Intel (others) for chip documentation, as well as security vulnearabilities:

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).

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?

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?



BSDCan last week: "Speculating on Speculation", Theo DeRadt
Disregard the drama, (relevant folks apologized already), focus on the meat of it all.
Also of interest to me as a user, defining various CPU features as "Chicken Bits", great vocabulary IMHO.

Colin Percival Tweeting about it, (post-embargo), "lazy FPU context switching":
As always, Colin's work is awesome here

Fun from the holiday season 2017, (and actually many months leading up to it), we all knew Spectre/Meltdown:

My thoughts from then, haven't changed now:
(Audio from an OWASP conference call where Intel and VMWare reps chickened out no-show):

More information about the talk mailing list