From wcblawoffices at gmail.com  Sat Jun  2 14:48:06 2018
From: wcblawoffices at gmail.com (wcblawoffices at gmail.com)
Date: Sat, 2 Jun 2018 14:48:06 -0400
Subject: [talk] talk Digest, Vol 172, Issue 19
In-Reply-To: <mailman.3.1527696001.36841.talk@lists.nycbug.org>
References: <mailman.3.1527696001.36841.talk@lists.nycbug.org>
Message-ID: <E4115A68-0383-456A-8619-5FEE03823FEF@gmail.com>

Isaac: https://www.investopedia.com/news/palo-alto-networks-stock-breaks-out-alltime-high/?utm_source=personalized&utm_campaign=www.investopedia.com&utm_term=13425739&utm_medium=email

Bill - manager
w: traderbrokerage.com
e: bill at traderbrokerage.com



Sent from my iPhone

> On May 30, 2018, at 12:00 PM, talk-request at lists.nycbug.org wrote:
> 
> Send talk mailing list submissions to
>    talk at lists.nycbug.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    http://lists.nycbug.org/mailman/listinfo/talk
> or, via email, send a message with subject or body 'help' to
>    talk-request at lists.nycbug.org
> 
> You can reach the person managing the list at
>    talk-owner at lists.nycbug.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of talk digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: So Netgate bails on FreeBSD (Izaac)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 30 May 2018 11:44:05 -0400
> From: Izaac <izaac at setec.org>
> To: NYCBUG Talk <talk at lists.nycbug.org>
> Subject: Re: [talk] So Netgate bails on FreeBSD
> Message-ID: <20180530T142533Z at localhost>
> Content-Type: text/plain; charset=utf-8
> 
>> On Sat, May 26, 2018 at 05:19:41PM +0000, Mark Saad wrote:
>> I think I?ll stop there, except to note to Izaac, we get calls from
>> PAN customers all the time.  pfSense can?t line up against PAN.  This
>> can.
> 
> I just shit-canned eight PANs and replaced them with pfSense on some
> ancient Dell R210s the other week.  I investigated what it would cost
> out-of-pocket to have a) them shredded and b) the remnants shipped to
> our rep.  I still may.
> 
> It felt really, really good.  And performance is better in nearly every
> respect.  The only issue is "selling" the idea to the our paranoid
> customers who associate the Palo Alto name with some fantasy of
> excellence.  So far, it's been effective to list the suite of packages,
> e.g. Suricata, and impress them with the sheer weight of text on
> multiple lines.
> 
> And this is the real problem.  It's not about the technology.  It's
> about perception and market inertia.
> 
> You've 100% done the right thing in coming out with a completely
> detached product marketed at the space.  There's no way pfSense would be
> satisfactorily whacked into an "Enterprise" form to make those people
> happy.  "Based on the experience of developing" is about the most you
> can get out of it.
> 
> But this market has nothing to do with technology and everything to do
> with the promotion of irrational decisions.  The prey are executives who
> desperately want to spend money on a thing so as to give the appearance
> of having "done" something about it to their board.  The predators are
> experienced.  They understand how to cultivate fear and offer relief.
> They know how to weasel their products into positions from which they
> can sell additional services.  They know how to cultivate drones who
> constantly push the product into further integrations and refuse to
> consider leaving.  Textbook psychopathy in a sales force.
> 
> Just read the commanding tone of this communication I got from them a
> month ago:
> 
>   Date: Mon, 30 Apr 2018 21:54:41 +0000
>   From: XXXXXXXX XXXXXXXX <XXXXXXXX at paloaltonetworks.com>
>   Subject: Time to take a second look
> 
>   Hello,
> 
>   [You] previously evaluated Palo Alto Networks. Unfortunately, we
>   went our separate ways. Since then, we released new hardware at lower
>   prices and our new operating system with enhancements for cloud,
>   phishing attacks, and more. It is worth another conversation.
> 
>   Let?s do an overview next Thursday afternoon? Let me know what time
>   works best for you.
> 
>   XXXXXXXX XXXXXXXX | Business Development Representative, XXXXXXXX
>   XXXXXXXX XXXXXXXX | Palo Alto Networks
> 
> Re-read it with the words "hey baby" in front for amusement.
> 
> I'm happy that I don't think you can compete with them at that level.
> Be better.  I'd hope and expect that if you build your strategy around
> being a competent alternative, you may have some luck -- and I genuinely
> wish you guys luck.
> 
> -- 
> . ___ ___  .   .  ___
> .  \    /  |\  |\ \
> .  _\_ /__ |-\ |-\ \__
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk
> 
> 
> ------------------------------
> 
> End of talk Digest, Vol 172, Issue 19
> *************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20180602/2d3ab8d4/attachment.htm>

From _ at thomaslevine.com  Tue Jun  5 18:59:18 2018
From: _ at thomaslevine.com (Thomas Levine)
Date: Tue, 05 Jun 2018 22:59:18 +0000
Subject: [talk] Outside meeting
In-Reply-To: <CAENxBwzPF-0XMXmS51Dex4hSE7WRiGRrRXpd6KbuXiHwB+XYOw@mail.gmail.com>
References: <20180510205248.4144AE47F2@mailuser.nyi.internal>
 <681BB578-A15A-461D-BF96-24FD426A64FF@gmail.com>
 <1526095436.2890602.1369397584.65B7624F@webmail.messagingengine.com>
 <20180520140743.49AEFE444F@mailuser.nyi.internal>
 <CAENxBwzPF-0XMXmS51Dex4hSE7WRiGRrRXpd6KbuXiHwB+XYOw@mail.gmail.com>
Message-ID: <20180605225918.656E6E40A3@mailuser.nyi.internal>

This meeting is tomorrow, 6:45 pm, at Bryant Park.
If you have trouble finding us, call me at (718) 594-3817.

Who is coming?

I acquired an easel but did not acquire anything to put on the easel.
If it is fewer than like seven people, normal paper without the easel
should be fine.

Edward Capriolo writes:
> On Sun, May 20, 2018 at 10:07 AM, Thomas Levine <_ at thomaslevine.com> wrote:
>
> > Then let us hold a meeting in Bryant Park on Wednesday, June 6 at 18:45
> > (the normal time of the month).
> >
> > We cancel it in case of rain, unless someone else has ideas.
> >
> > Can anyone bring an easel or chalkboard? If not, I will acquire and
> > bring them, or something equivalent.
> >
> > We can propose presentations now, or not.
> >
> > _______________________________________________
> > talk mailing list
> > talk at lists.nycbug.org
> > http://lists.nycbug.org/mailman/listinfo/talk
> >
>
> There is no sandbox or patch of dirt? That would make it super official.



From _ at thomaslevine.com  Tue Jun  5 19:32:17 2018
From: _ at thomaslevine.com (Thomas Levine)
Date: Tue, 05 Jun 2018 23:32:17 +0000
Subject: [talk] Outside meeting
In-Reply-To: <1528241330.3320168.1397766232.1A52540D@webmail.messagingengine.com>
References: <20180510205248.4144AE47F2@mailuser.nyi.internal>
 <681BB578-A15A-461D-BF96-24FD426A64FF@gmail.com>
 <1526095436.2890602.1369397584.65B7624F@webmail.messagingengine.com>
 <20180520140743.49AEFE444F@mailuser.nyi.internal>
 <CAENxBwzPF-0XMXmS51Dex4hSE7WRiGRrRXpd6KbuXiHwB+XYOw@mail.gmail.com>
 <20180605225918.656E6E40A3@mailuser.nyi.internal>
 <1528241330.3320168.1397766232.1A52540D@webmail.messagingengine.com>
Message-ID: <20180605233217.AD2F4E47F2@mailuser.nyi.internal>

Peter Varga writes:
> The best idea of NYCBUG was anonymity we all appreciate: no sign up, no
> membership fee, no commitment.  Just like minded humans get together
> and share.

Yeah okay

I doubt based on recent attendance and mailing list commentary
that seven people will come, so I'm bringing paper and no easel.



From george at ceetonetechnology.com  Tue Jun  5 19:48:00 2018
From: george at ceetonetechnology.com (George Rosamond)
Date: Tue, 05 Jun 2018 23:48:00 +0000
Subject: [talk] Outside meeting
In-Reply-To: <20180605233217.AD2F4E47F2@mailuser.nyi.internal>
References: <20180510205248.4144AE47F2@mailuser.nyi.internal>
 <681BB578-A15A-461D-BF96-24FD426A64FF@gmail.com>
 <1526095436.2890602.1369397584.65B7624F@webmail.messagingengine.com>
 <20180520140743.49AEFE444F@mailuser.nyi.internal>
 <CAENxBwzPF-0XMXmS51Dex4hSE7WRiGRrRXpd6KbuXiHwB+XYOw@mail.gmail.com>
 <20180605225918.656E6E40A3@mailuser.nyi.internal>
 <1528241330.3320168.1397766232.1A52540D@webmail.messagingengine.com>
 <20180605233217.AD2F4E47F2@mailuser.nyi.internal>
Message-ID: <c9845616-cd08-6ba7-468c-b93aaa08d4e7@ceetonetechnology.com>



Thomas Levine:
> Peter Varga writes:
>> The best idea of NYCBUG was anonymity we all appreciate: no sign up, no
>> membership fee, no commitment.  Just like minded humans get together
>> and share.
> 
> Yeah okay
> 
> I doubt based on recent attendance and mailing list commentary
> that seven people will come, so I'm bringing paper and no easel.

I can hit announce@ list about it... although I can't make it.

Where in Bryant Park?

g



From pvarga at pvrg.net  Tue Jun  5 19:54:44 2018
From: pvarga at pvrg.net (Peter Varga)
Date: Tue, 05 Jun 2018 23:54:44 +0000
Subject: [talk] Outside meeting
In-Reply-To: <c9845616-cd08-6ba7-468c-b93aaa08d4e7@ceetonetechnology.com>
References: <20180510205248.4144AE47F2@mailuser.nyi.internal>
 <681BB578-A15A-461D-BF96-24FD426A64FF@gmail.com>
 <1526095436.2890602.1369397584.65B7624F@webmail.messagingengine.com>
 <20180520140743.49AEFE444F@mailuser.nyi.internal>
 <CAENxBwzPF-0XMXmS51Dex4hSE7WRiGRrRXpd6KbuXiHwB+XYOw@mail.gmail.com>
 <20180605225918.656E6E40A3@mailuser.nyi.internal>
 <1528241330.3320168.1397766232.1A52540D@webmail.messagingengine.com>
 <20180605233217.AD2F4E47F2@mailuser.nyi.internal>
 <c9845616-cd08-6ba7-468c-b93aaa08d4e7@ceetonetechnology.com>
Message-ID: <1528242884.3329383.1397785000.17D99FD3@webmail.messagingengine.com>

Bryant Park is an easy 5 minutes walk all around nyc publicity library.

On Tue, Jun 5, 2018, at 23:48, George Rosamond wrote:
>
>
> Thomas Levine:
> > Peter Varga writes:
> >> The best idea of NYCBUG was anonymity we all appreciate: no sign
> >> up, no> >> membership fee, no commitment.  Just like minded humans get
> >> together> >> and share.
> >
> > Yeah okay
> >
> > I doubt based on recent attendance and mailing list commentary
> > that seven people will come, so I'm bringing paper and no easel.
>
> I can hit announce@ list about it... although I can't make it.
>
> Where in Bryant Park?
>
> g
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20180605/64b338dc/attachment.htm>

From george at ceetonetechnology.com  Tue Jun  5 19:56:00 2018
From: george at ceetonetechnology.com (George Rosamond)
Date: Tue, 05 Jun 2018 23:56:00 +0000
Subject: [talk] Outside meeting
In-Reply-To: <1528242884.3329383.1397785000.17D99FD3@webmail.messagingengine.com>
References: <20180510205248.4144AE47F2@mailuser.nyi.internal>
 <681BB578-A15A-461D-BF96-24FD426A64FF@gmail.com>
 <1526095436.2890602.1369397584.65B7624F@webmail.messagingengine.com>
 <20180520140743.49AEFE444F@mailuser.nyi.internal>
 <CAENxBwzPF-0XMXmS51Dex4hSE7WRiGRrRXpd6KbuXiHwB+XYOw@mail.gmail.com>
 <20180605225918.656E6E40A3@mailuser.nyi.internal>
 <1528241330.3320168.1397766232.1A52540D@webmail.messagingengine.com>
 <20180605233217.AD2F4E47F2@mailuser.nyi.internal>
 <c9845616-cd08-6ba7-468c-b93aaa08d4e7@ceetonetechnology.com>
 <1528242884.3329383.1397785000.17D99FD3@webmail.messagingengine.com>
Message-ID: <8facd5a8-d284-5da8-2ca2-c358637ce2e2@ceetonetechnology.com>



Peter Varga:
> Bryant Park is an easy 5 minutes walk all around nyc publicity library.

Yes... I have (vaguely) heard of that place somewhere...

seriously, it makes sense to pick a corner by direction (eg, "northeast
corner") by chairs or on the grass.

If the weather is decent, you won't stick out.

LMK so I can put in an announce.

g



From pvarga at pvrg.net  Tue Jun  5 19:59:37 2018
From: pvarga at pvrg.net (Peter Varga)
Date: Tue, 05 Jun 2018 23:59:37 +0000
Subject: [talk] Outside meeting
In-Reply-To: <8facd5a8-d284-5da8-2ca2-c358637ce2e2@ceetonetechnology.com>
References: <20180510205248.4144AE47F2@mailuser.nyi.internal>
 <681BB578-A15A-461D-BF96-24FD426A64FF@gmail.com>
 <1526095436.2890602.1369397584.65B7624F@webmail.messagingengine.com>
 <20180520140743.49AEFE444F@mailuser.nyi.internal>
 <CAENxBwzPF-0XMXmS51Dex4hSE7WRiGRrRXpd6KbuXiHwB+XYOw@mail.gmail.com>
 <20180605225918.656E6E40A3@mailuser.nyi.internal>
 <1528241330.3320168.1397766232.1A52540D@webmail.messagingengine.com>
 <20180605233217.AD2F4E47F2@mailuser.nyi.internal>
 <c9845616-cd08-6ba7-468c-b93aaa08d4e7@ceetonetechnology.com>
 <1528242884.3329383.1397785000.17D99FD3@webmail.messagingengine.com>
 <8facd5a8-d284-5da8-2ca2-c358637ce2e2@ceetonetechnology.com>
Message-ID: <1528243177.3330587.1397787960.21B3E0BE@webmail.messagingengine.com>


Yes all weather is nice to a real nyc dweller.  Lol

On Tue, Jun 5, 2018, at 23:56, George Rosamond wrote:
>
>
> Peter Varga:
> > Bryant Park is an easy 5 minutes walk all around nyc publicity
> > library.>
> Yes... I have (vaguely) heard of that place somewhere...
>
> seriously, it makes sense to pick a corner by direction (eg,
> "northeast> corner") by chairs or on the grass.
>
> If the weather is decent, you won't stick out.
>
> LMK so I can put in an announce.
>
> g
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20180605/07960ac4/attachment.htm>

From _ at thomaslevine.com  Tue Jun  5 20:26:28 2018
From: _ at thomaslevine.com (Thomas Levine)
Date: Wed, 06 Jun 2018 00:26:28 +0000
Subject: [talk] Outside meeting
In-Reply-To: <8facd5a8-d284-5da8-2ca2-c358637ce2e2@ceetonetechnology.com>
References: <20180510205248.4144AE47F2@mailuser.nyi.internal>
 <681BB578-A15A-461D-BF96-24FD426A64FF@gmail.com>
 <1526095436.2890602.1369397584.65B7624F@webmail.messagingengine.com>
 <20180520140743.49AEFE444F@mailuser.nyi.internal>
 <CAENxBwzPF-0XMXmS51Dex4hSE7WRiGRrRXpd6KbuXiHwB+XYOw@mail.gmail.com>
 <20180605225918.656E6E40A3@mailuser.nyi.internal>
 <1528241330.3320168.1397766232.1A52540D@webmail.messagingengine.com>
 <20180605233217.AD2F4E47F2@mailuser.nyi.internal>
 <c9845616-cd08-6ba7-468c-b93aaa08d4e7@ceetonetechnology.com>
 <1528242884.3329383.1397785000.17D99FD3@webmail.messagingengine.com>
 <8facd5a8-d284-5da8-2ca2-c358637ce2e2@ceetonetechnology.com>
Message-ID: <20180606002629.6A1BEE40A3@mailuser.nyi.internal>

On the grass

And actually I will bring an easel.

Please, somebody bring a piece of cardboard, or we can look for one in
the garbage.



From george at ceetonetechnology.com  Wed Jun  6 11:26:00 2018
From: george at ceetonetechnology.com (George Rosamond)
Date: Wed, 06 Jun 2018 15:26:00 +0000
Subject: [talk] NYC*BUG Tonight in Bryant Park
Message-ID: <3cec930f-09bc-93fb-4fef-594412edf155@ceetonetechnology.com>

A group of NYC*BUG people are congregating in Bryant Park on 6th Avenue
between 41st and 42nd Street some place on the grass at 645 PM.

A large pad will be the digital projector, the grass will be the seating.

Chime in on talk@ if you have any questions.



From kmsujit at gmail.com  Fri Jun  8 10:20:35 2018
From: kmsujit at gmail.com (Sujit K M)
Date: Fri, 8 Jun 2018 19:50:35 +0530
Subject: [talk] GEOM
Message-ID: <CA+6mNerwQC1Fz6BZ2pP6_kW=ia8pL6e56dHGb1L+HO_pPbvLZA@mail.gmail.com>

Hi All,

I tried installing 11.1 FreeBSD on my hardware. Which I must say is an
proprietary one(HP). I see that during install options to select the filesystem
it doesn't allow me to select size or mount points as said I could not install
FreeBSD on my system.

I tried Ubuntu then 18.04, It has issues with GRUB2 EFI, and doesn't install
the OS. Corrupts boot loader.

Any one interested in knowing what I did to install the boot loader. Which
Already had Windows 8.1, I had the Disc and Choose Repair on Command
line and issued the command listed below.

bootrec /fixmbr

bootrec /fixboot

In sequence. Could someone help me with details regarding GEOM which should
be the reason I am not able to install FreeBSD 11.1.

Regards,
Sujit K M



From mcevoy.pat at gmail.com  Wed Jun 13 06:44:41 2018
From: mcevoy.pat at gmail.com (Patrick McEvoy)
Date: Wed, 13 Jun 2018 06:44:41 -0400
Subject: [talk] NYC*BUG Tonight in Bryant Park
In-Reply-To: <3cec930f-09bc-93fb-4fef-594412edf155@ceetonetechnology.com>
References: <3cec930f-09bc-93fb-4fef-594412edf155@ceetonetechnology.com>
Message-ID: <5B20F599.4090204@gmail.com>

George Rosamond wrote:
> A group of NYC*BUG people are congregating in Bryant Park on 6th Avenue
> between 41st and 42nd Street some place on the grass at 645 PM.
> 
> A large pad will be the digital projector, the grass will be the seating.
> 
> Chime in on talk@ if you have any questions.

Hey folks,
How did the meeting go please? We should update the website about the
meeting and would like to have some details please.
P



From ike at blackskyresearch.net  Sun Jun 17 15:59:01 2018
From: ike at blackskyresearch.net (Isaac (.ike) Levy)
Date: Sun, 17 Jun 2018 15:59:01 -0400
Subject: [talk] Embargo/Foundation questions, Intel CPU/speculation bugs
Message-ID: <1529265541.2284010.1410992600.1C32FB9A@webmail.messagingengine.com>

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?

Best,
.ike


--
Context:

BSDCan last week: "Speculating on Speculation", Theo DeRadt
https://www.youtube.com/watch?v=UaQpvXSa4X8
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":
?https://twitter.com/cperciva/status/1007010583244230656
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:
https://www.kb.cert.org/vuls/id/584653

My thoughts from then, haven't changed now:
(Audio from an OWASP conference call where Intel and VMWare reps chickened out no-show):
https://drive.google.com/file/d/1fkNfl1RTGiEFZ8PzjW_GTu3F1VK6WFp_/view



From shawn.webb at hardenedbsd.org  Sun Jun 17 16:44:36 2018
From: shawn.webb at hardenedbsd.org (Shawn Webb)
Date: Sun, 17 Jun 2018 16:44:36 -0400
Subject: [talk] Embargo/Foundation questions, Intel CPU/speculation bugs
In-Reply-To: <1529265541.2284010.1410992600.1C32FB9A@webmail.messagingengine.com>
References: <1529265541.2284010.1410992600.1C32FB9A@webmail.messagingengine.com>
Message-ID: <20180617204436.emn6cxzugjak6yxe@mutt-hbsd>

On Sun, Jun 17, 2018 at 03:59:01PM -0400, 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 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?
> 
> Best,
> .ike

Hey Ike,

Thank you for sharing your thoughts and starting this much-needed
discussion. I'm in the process of gathering my thoughts and writing a
rather lengthy article.  I've pasted below an incomplete rough draft.
I still have a lot more to write and I'm gethering input from a few
other peeps, both individuals and businesses. I cannot stress enough
that this is an _incomplete_ and _rough_ draft. I'm no where close to
finished with it, yet.

It's in Markdown format.

Full Disclosure Versus Responsible Disclosure
=============================================

Very special and crucial note: This article discusses my personal
feelings regarding vulnerability disclosure methods. This article is
not written on behalf of HardenedBSD. This article does NOT reflect
the opinions, beliefs, or actions of The HardenedBSD Project.

Meltdown and Spectre, along with the other CPU microarchitecture
speculation vulnerabilities, will be the prime use case in this
article.

It's fine if you don't agree with this article. If everyone held my
same opinions and beliefs, the world would be a very boring place.
Diverse thought makes experiencing and living in this world exciting.

My goal with this article is to start a much-needed discussion. I hope
we in the infosec industry can learn from recent events and move
forward together.

Definitions
-----------

We live in a time when vendors prefer security researchers disclose
newly-found vulnerabilities responsibly. We don't have a firm
definition of what "responsible disclosure" is, though. Usually,
researchers will follow this pattern:

1. Researcher finds exploitable vulnerability
1. Researcher notifies vendor, giving a projected embargo date
1. Vendor resolves issues prior to expiration of embargo
1. Researcher and vendor release a joint announcement

This workflow typically works when the vendor produces easy-to-update
products that don't have many (or any) downstream dependent consumers.
Firefox is an easy example. All Mozilla has to do is fix the bug and
cut a new release. The package maintainers for the various operating
systems will perform a version bump and the problem is largely solved.

The definition of "Responsible Disclosure" becomes murky when a
researcher finds a vulnerability in a hard-to-update product used in a
massive scale, like Intel CPUs. Sure, Intel should be notified, but
certain vulnerabilities have much larger impact than Intel's
product line by itself. Meltdown and Spectre provide an excellent case
study.

Thus, when we define "Responsible Disclosure," we also need to define
"Coordinated Disclosure." Vendors must responsibly decide which
downstream projects get notified and in which order.

The Coordinated Disclosure Problem
----------------------------------

A lot of business today is about relationships. This is especially
true in information security. We value the opinions of people we know
and trust and distrust everyone else.

When a vendor receives a security notification, the vendor must
evaluate who could be impacted and of those impacted, who to notify.
Coordinated disclosures usually come with either a Non-Disclosure
Agreement (NDA) or an embargo until a specified date. The vendor can
choose to collaborate with zero or more impacted entities of the
vendor's own choosing.

When Intel received notice from Google regarding Meltdown and Spectre,
Intel chose to notify only a few larger entities (eg, Amazon, Google,
and Linux). Those entities got a six-month advanced notice and had at
least some semblance of a fix the day the story broke in January 2018.
FreeBSD received notice the week around Christmas 2017 only after
certain researchers in-the-know pushed Intel hard to notify FreeBSD.
Smaller hosting companies and all of the other BSDs were left out.

Thus, Intel only coordinated the disclosure with a few larger players.
Favoritism is at play here. Such favoritism has a direct impact on the
economy of the less fortunate. Why would I go with a smaller hosting
provider when Amazon receives and can take action on advanced
vulnerability notifications? If security is of any concern, I should
only use Amazon's and Google's services. Screw the smaller players,
right?

Coordinated disclosure, as currently performed, should be called
unethical selective disclosure. Pay the right people your agreed
extortion, and you're now on the favorites list. When did it become
acceptable to pay someone to tell you you're vulnerable because of
their mistakes?

The Case For Full Disclosure
----------------------------

Since so-called responsible disclosure inevitably leads to greed and
extortion, full disclosure is the responsible way forward. All
downstream vendors become equals.

Full disclosure lends itself to a better collaborative effort. Now
that all entities are on equal footing, they can work together to
provide their communities the best quality fix. No one single vendor
has an omniscient developer capable of writing "the perfect fix." If
vendors work side-by-side, they can anticipate future problems along
with providing innovative fixes and mitigations for current issues.

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        lattera at is.a.hacker.sx
GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20180617/0508a751/attachment.bin>

From gnn at neville-neil.com  Mon Jun 18 05:24:24 2018
From: gnn at neville-neil.com (George Neville-Neil)
Date: Mon, 18 Jun 2018 17:24:24 +0800
Subject: [talk] Embargo/Foundation questions, Intel CPU/speculation bugs
In-Reply-To: <1529265541.2284010.1410992600.1C32FB9A@webmail.messagingengine.com>
References: <1529265541.2284010.1410992600.1C32FB9A@webmail.messagingengine.com>
Message-ID: <5708B3A6-D49F-4C06-B41E-3F150B6A56E3@neville-neil.com>

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 
> foundation?
> 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 
later.

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

Best,
George



From ike at blackskyresearch.net  Mon Jun 18 14:36:13 2018
From: ike at blackskyresearch.net (Isaac (.ike) Levy)
Date: Mon, 18 Jun 2018 14:36:13 -0400
Subject: [talk] Embargo/Foundation questions, Intel CPU/speculation bugs
In-Reply-To: <5708B3A6-D49F-4C06-B41E-3F150B6A56E3@neville-neil.com>
References: <1529265541.2284010.1410992600.1C32FB9A@webmail.messagingengine.com>
 <5708B3A6-D49F-4C06-B41E-3F150B6A56E3@neville-neil.com>
Message-ID: <1529346973.1441163.1412044912.3D58AC8B@webmail.messagingengine.com>

Appreciate your time and thoughtful response GNN, 2 big questions remain, specific to FreeBSD:

- What benefit have the vendor NDA's had for the FreeBSD project (particularly Intel)?

- What negative effects have vendor NDA's had on the FreeBSD project?


These are the only two questions that really matter, more commentary for anyone with time to spend on it:

Worth me stating ahead of my commentary (for folks on list who don't know me or GNN), I have profound respect for GNN's epic work on FreeBSD, from core Networking, to comprehensive OS internals, his code touches us all in some way we cherish.  We're all better off because of GNN's publishing and educational work, as well as the time he's spent toiling for the Foundation- the list goes on and on.

Just wanted to state this up front so it's clear in this discourse that I'm aiming to keep this thread and any disagreement focused on constructive understanding of the issues, and all our common aim to keep working for *BSD systems to be as strong as ever.
Even though I'm a mere mortal, I'll certainly say that GNN and myself are every bit as invested in *BSD thriving, as so many of us are here.

On Mon, Jun 18, 2018, at 5:24 AM, George Neville-Neil wrote:
> 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 
> > foundation?
> > 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.

Thanks for clarifying this, coordinating an shepherding the NDA's with proper legal counsel sounds like a massive task!
The Foundation certainly does seem to be the place for this level of coordination to happen- (to keep the codebase in a known state with regard to various legalities).  Far better than over in Linux-land, where who knows who's got what NDA priviliged commit coming into what parts of the tree...

For example, in the Linux Kernel, it became quite obvious when Spectre/Meltdown was about to hit the street, that even Linus wasn't at all privvy to what was happening:
https://lkml.org/lkml/2018/1/3/797
(an interesting post on many levels.)

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

I get that- but to clarify, I'm certainly not looking for a sign saying "get in line here for NDA privileged information".

As a user of FreeBSD, with my own concerns, I simply would prefer to understand more clearly what these NDA's impose on the codebase, and also what they provide, to the FreeBSD project.  Worthy of a blurb describing the scope of this critical effort under the "What We Do" tab, etc...

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

I may be wrong here, but chip docs for stuff like these latest speculative execution and cache bugs, don't appear to be well documented  at all, (even with NDA)?  Is this a qbit- whereby the chip is simultaneously documented, and not documented, and also concurrently has a state which requires NDA?  I kid- I understand the scale and complexity of publishing relevant docs on fast moving hardware in our world- yet I don't understand where it's acceptable to step over a line into NDA territory.

Also, from Theo's BSDCan talk, the fun clarifying vocabulary of "Chicken Bits", (features on chips which are part of future features, baked into the die early- or perhaps never seeing the light of day- these require NDA- in recent years exposed only through security vulns, forcing vendor response documentation.)

Vulnerabilities that pop up from these "Chicken Bits", have had a profound effect on my professional life as a sysadmin/engineer in recent years.

To date, I don't see evidence that any NDA process here is mitigating anything for anybody, except perhaps mitigating dips in Intel's stock value.  I'd love to see the evidence which can change my mind!

Additionally, these issues are far from new or unique to the *BSD's, - as in the BlackHat/Defcon/CCC/ShmooCon/etc universe, Intel CPU vulnerabilities have been more frequent and more damaging every year for some years.  (And often, the technical details are absurdly inane- the issues are boneheaded- the secrecy and profound impact of the vluns is what's made them such a hot topic).

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

With all due respect to everyone working toward fixes/mitigations, the esoteric nature of many important security vulnerabilities cannot ever be comprehensively handled by any single organization.  I do not see evidence here that maintaining NDA-backed secrecy is helping increase the number of hands- capable volunteers who are subject matter experts.

In my 20 years running internet-facing infrastructure, the most effective security responses in the world have often been mitigated/resolved by the parties which care most about them, (and understand them), not by teams dedicated to be solely responsible for solving everything.

And for things like the recent speculation bugs: it breaks my heart to see so many *great minds* with better things to do for the OS, get mired in bit-flipping on cache invalidation.  Even as an outsider who's never hacked on that subsystem, these problems look like an outright inane distraction for FreeBSD or any OS.  So again here, I fail to see why playing by Intel's rules (with NDA) helps us all transcend past these issues?

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

I can't agree more regarding leaks.
If one agrees to the rules, one must play by them - or face the consequences (loosing trust, here).

However, I'm well beyond that here.  I'm questioning the decision to engage the NDA's in the first place.

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

I understand a modern CPU is complicated- no doubt.  Yet, doing reasonable OS work for Intel CPU's requires NDA to get proper docs?

I mean, I'd much rather just start seeing more pressure on Intel to simply publish more transparently.
And if our relatively smaller *BSD voice isn't enough, I'm certain there are plenty of folks in the Linux multiverse who would agree:
(Again, Linus reaction to Meltdown/Spectre <https://lkml.org/lkml/2018/1/3/797>)

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

I think you just threw a very good project out to someone in the world then :)
Any capable hands who have read this far: I'd be delighted to play support/sysadmin role for any required servers in the NYC*BUG cabinet for someone doing this sort of work!  :)  (call it d-messy-db, to match nycbug dmesgdb?)

Best,
.ike


> 
> Best,
> George
> 



From kmsujit at gmail.com  Thu Jun 21 11:02:10 2018
From: kmsujit at gmail.com (Sujit K M)
Date: Thu, 21 Jun 2018 20:32:10 +0530
Subject: [talk] Embargo/Foundation questions, Intel CPU/speculation bugs
In-Reply-To: <1529346973.1441163.1412044912.3D58AC8B@webmail.messagingengine.com>
References: <1529265541.2284010.1410992600.1C32FB9A@webmail.messagingengine.com>
 <5708B3A6-D49F-4C06-B41E-3F150B6A56E3@neville-neil.com>
 <1529346973.1441163.1412044912.3D58AC8B@webmail.messagingengine.com>
Message-ID: <CA+6mNergSOvKaNCeN481xe0hTifLR8dp9SaX_wnzvscdt8K4vw@mail.gmail.com>

On Tue, Jun 19, 2018 at 12:06 AM, Isaac (.ike) Levy
<ike at blackskyresearch.net> wrote:
> Appreciate your time and thoughtful response GNN, 2 big questions remain, specific to FreeBSD:
>
> - What benefit have the vendor NDA's had for the FreeBSD project (particularly Intel)?

I see that FreeBSD patches are more correct than Linux. As claimed by
Linus Himself(only Linux Part,
I don't think he knows FreeBSD).

> - What negative effects have vendor NDA's had on the FreeBSD project?

As per me, NDA's contain the same document for any project be
proprietary/open source. If they are
are having a different view point for say proprietary OSes then It is
hitting FreeBSD in a big way.

I see NDA's are Cryptic was of hiding Intel's chipset features, Which
should be as Intel won't let any
one else take advantage of the current situation currently or in
future. It now depends on FreeBSD
project how they tackle and ensure that the patch released is correct
and is preventing the security holes.
I would suggest INFOSec companies to ensure this too as a part of
their credibility.



From gnn at neville-neil.com  Thu Jun 21 11:13:19 2018
From: gnn at neville-neil.com (George Neville-Neil)
Date: Thu, 21 Jun 2018 23:13:19 +0800
Subject: [talk] Embargo/Foundation questions, Intel CPU/speculation bugs
In-Reply-To: <1529346973.1441163.1412044912.3D58AC8B@webmail.messagingengine.com>
References: <1529265541.2284010.1410992600.1C32FB9A@webmail.messagingengine.com>
 <5708B3A6-D49F-4C06-B41E-3F150B6A56E3@neville-neil.com>
 <1529346973.1441163.1412044912.3D58AC8B@webmail.messagingengine.com>
Message-ID: <35578374-1E84-44B2-AA14-3510FFA7AA8F@neville-neil.com>

The short answer is that without the NDAs we'd be shut out of a lot more 
things than we're already shut out of.  One of the reasons we have 
excellent support for high speed NICs (SolarFlare, Chelsio, Mellanox 
etc.) is due to the FF signing NDAs, getting things in place and then, 
when the time was right, getting developers at those companies to do the 
right things for us.  We can see this in other areas as well, graphics 
etc.  It also helps that companies like NetFlix, Hudson River (my former 
employer), Netgate and others have stepped up to demand access for 
FreeBSD, but access comes at a price, and, it's relatively impossible 
for a lone developer to get this stuff in place, at least for the 
hardware that matters.

I have yet to see a negative effect.  Generally there aren't that many 
people who can effectively do the work that an NDA is useful for.  It's 
not like there are 100 competent graphics driver writers on Earth, and 
if there were, I'd simply get them all under an NDA through the FF and 
off we'd go.  The fact of the matter is we're talking about < 10 people 
per area or per device provider (even Intel) who really need this kind 
of access.

In the end if we want to be able to be at the cutting edge of new 
hardware we're going to have to play ball with these folks, and that's 
what the FF is there for, to be the folks who have lawyers, and sign 
contracts and NDAs and help the community engage with the folks making 
the chips.

Best,
George

On 19 Jun 2018, at 2:36, Isaac (.ike) Levy wrote:

> Appreciate your time and thoughtful response GNN, 2 big questions 
> remain, specific to FreeBSD:
>
> - What benefit have the vendor NDA's had for the FreeBSD project 
> (particularly Intel)?
>
> - What negative effects have vendor NDA's had on the FreeBSD project?
>
>
> These are the only two questions that really matter, more commentary 
> for anyone with time to spend on it:
>
> Worth me stating ahead of my commentary (for folks on list who don't 
> know me or GNN), I have profound respect for GNN's epic work on 
> FreeBSD, from core Networking, to comprehensive OS internals, his code 
> touches us all in some way we cherish.  We're all better off because 
> of GNN's publishing and educational work, as well as the time he's 
> spent toiling for the Foundation- the list goes on and on.
>
> Just wanted to state this up front so it's clear in this discourse 
> that I'm aiming to keep this thread and any disagreement focused on 
> constructive understanding of the issues, and all our common aim to 
> keep working for *BSD systems to be as strong as ever.
> Even though I'm a mere mortal, I'll certainly say that GNN and myself 
> are every bit as invested in *BSD thriving, as so many of us are here.
>
> On Mon, Jun 18, 2018, at 5:24 AM, George Neville-Neil wrote:
>> 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
>>> foundation?
>>> 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.
>
> Thanks for clarifying this, coordinating an shepherding the NDA's with 
> proper legal counsel sounds like a massive task!
> The Foundation certainly does seem to be the place for this level of 
> coordination to happen- (to keep the codebase in a known state with 
> regard to various legalities).  Far better than over in Linux-land, 
> where who knows who's got what NDA priviliged commit coming into what 
> parts of the tree...
>
> For example, in the Linux Kernel, it became quite obvious when 
> Spectre/Meltdown was about to hit the street, that even Linus wasn't 
> at all privvy to what was happening:
> https://lkml.org/lkml/2018/1/3/797
> (an interesting post on many levels.)
>
>>
>>> 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.
>
> I get that- but to clarify, I'm certainly not looking for a sign 
> saying "get in line here for NDA privileged information".
>
> As a user of FreeBSD, with my own concerns, I simply would prefer to 
> understand more clearly what these NDA's impose on the codebase, and 
> also what they provide, to the FreeBSD project.  Worthy of a blurb 
> describing the scope of this critical effort under the "What We Do" 
> tab, etc...
>
>>
>>> 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.
>
> I may be wrong here, but chip docs for stuff like these latest 
> speculative execution and cache bugs, don't appear to be well 
> documented  at all, (even with NDA)?  Is this a qbit- whereby the chip 
> is simultaneously documented, and not documented, and also 
> concurrently has a state which requires NDA?  I kid- I understand the 
> scale and complexity of publishing relevant docs on fast moving 
> hardware in our world- yet I don't understand where it's acceptable to 
> step over a line into NDA territory.
>
> Also, from Theo's BSDCan talk, the fun clarifying vocabulary of 
> "Chicken Bits", (features on chips which are part of future features, 
> baked into the die early- or perhaps never seeing the light of day- 
> these require NDA- in recent years exposed only through security 
> vulns, forcing vendor response documentation.)
>
> Vulnerabilities that pop up from these "Chicken Bits", have had a 
> profound effect on my professional life as a sysadmin/engineer in 
> recent years.
>
> To date, I don't see evidence that any NDA process here is mitigating 
> anything for anybody, except perhaps mitigating dips in Intel's stock 
> value.  I'd love to see the evidence which can change my mind!
>
> Additionally, these issues are far from new or unique to the *BSD's, - 
> as in the BlackHat/Defcon/CCC/ShmooCon/etc universe, Intel CPU 
> vulnerabilities have been more frequent and more damaging every year 
> for some years.  (And often, the technical details are absurdly inane- 
> the issues are boneheaded- the secrecy and profound impact of the 
> vluns is what's made them such a hot topic).
>
>>
>>> 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.
>
> With all due respect to everyone working toward fixes/mitigations, the 
> esoteric nature of many important security vulnerabilities cannot ever 
> be comprehensively handled by any single organization.  I do not see 
> evidence here that maintaining NDA-backed secrecy is helping increase 
> the number of hands- capable volunteers who are subject matter 
> experts.
>
> In my 20 years running internet-facing infrastructure, the most 
> effective security responses in the world have often been 
> mitigated/resolved by the parties which care most about them, (and 
> understand them), not by teams dedicated to be solely responsible for 
> solving everything.
>
> And for things like the recent speculation bugs: it breaks my heart to 
> see so many *great minds* with better things to do for the OS, get 
> mired in bit-flipping on cache invalidation.  Even as an outsider 
> who's never hacked on that subsystem, these problems look like an 
> outright inane distraction for FreeBSD or any OS.  So again here, I 
> fail to see why playing by Intel's rules (with NDA) helps us all 
> transcend past these issues?
>
>>
>>> 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
>> later.
>
> I can't agree more regarding leaks.
> If one agrees to the rules, one must play by them - or face the 
> consequences (loosing trust, here).
>
> However, I'm well beyond that here.  I'm questioning the decision to 
> engage the NDA's in the first place.
>
>>
>>> 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 :-)
>
> I understand a modern CPU is complicated- no doubt.  Yet, doing 
> reasonable OS work for Intel CPU's requires NDA to get proper docs?
>
> I mean, I'd much rather just start seeing more pressure on Intel to 
> simply publish more transparently.
> And if our relatively smaller *BSD voice isn't enough, I'm certain 
> there are plenty of folks in the Linux multiverse who would agree:
> (Again, Linus reaction to Meltdown/Spectre 
> <https://lkml.org/lkml/2018/1/3/797>)
>
>> 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...
>
> I think you just threw a very good project out to someone in the world 
> then :)
> Any capable hands who have read this far: I'd be delighted to play 
> support/sysadmin role for any required servers in the NYC*BUG cabinet 
> for someone doing this sort of work!  :)  (call it d-messy-db, to 
> match nycbug dmesgdb?)
>
> Best,
> .ike
>
>
>>
>> Best,
>> George
>>