
An Open Letter from Brian Krzanich, CEO of Intel, to Technology Industry Leaders - el_duderino
https://newsroom.intel.com/news-releases/security-first-pledge/
======
Chaebixi
> Security-First Pledge

So, I take it Intel will be sharing lots of info about the Intel ME, as well
as supported ways of disabling it? Or am I getting my hopes up?

~~~
sverige
I think you are reading this bit of PR far too optimistically.

For example, where in this statement does it say that Intel is actually going
to change the way they design their chips to make them more secure? It
doesn't. It only says that they will be more transparent about disclosing
vulnerabilities, and presumably that means they will continue to disclose
those security holes to the so-called "Tier 1" group, which excludes quite a
few projects.

The most interesting thing to me was the subtle shift of responsibility onto
vendors and consumers to make sure to patch their broken hardware promptly.

------
wadkar
> In particular, we want to thank the Google Project Zero team for practicing
> responsible disclosure, creating the opportunity for the industry to address
> these new issues in a coordinated fashion.

I understand this a PR piece, and thus the use of the term "responsible
disclosure". I believe the HN community disapproves of this terminology, and
prefers usage of the term "coordinated disclosure".

The question that I had was whether Google's project zero team prefers one
term over another? Or in general, if you're a security researcher and have
involved in reporting vulnerabilities - can you take a stand and emphasize
"coordinated disclosure" term in your own articles?

Edit: typos

~~~
Density
Thanks for pointing out this little gem. I hope Google can be a little less
responsible for independent company intel in the future.

~~~
dogma1138
Google didn't respect the embargo for the financial sake of Intel but for both
it's own sake and the sake of all of it's users, as well as most computer
users out there regardless if they use Google services or not.

Sure Intel put a PR spin on it, but any company would do that, but at least
the patches were ready from the get go even tho the information started
leaking a week prior to the official embargo date.

Would you rather having to wait 2-4 months without any mitigating solutions
other than turning off your PC?

People are focusing too much on Meltdown, it's not the worse variant of
Spectre, Variant 2 is much worse, and the possibility of future variants is
even scarier.

I don't see anything wrong with companies spending 5-6 months on coordinating
mitigation and fixes as well as building knowledge that can be used for future
research and prevention of similar vulnerabilities.

~~~
whyever
You seem to be assuming no one else found and exploited the vulnerability in
the meantime.

~~~
dogma1138
Say someone has found it before, it's likely better to have 1 nation state
exploiting it for 3 more months longer than every script kiddy on the block.

These vulnerabilities affect nearly every CPU on the planet across all major
CPU vendors, this isn't something your disclose immediately to teach someone a
lesson or just to watch the world burn.

Do you think Google would want to leave their infrastructure vulnerable for
months?

------
rabboRubble
I am curious how the BIOS/Firmware updates will be managed. Microsoft points
to manufacturer. Manufacturer may 1) not be in the consumer personal computer
market, or 2) even if the manufacturer is still in the business of selling
computers may no longer be supporting specific devices. I'm specifically
thinking of Toshiba, but there may be other examples out there.

Ideally there will be a way to safely update BIOS/firmware directly from
Intel.

~~~
dogma1138
You don't need to wait for a BIOS update.

On Linux download the microcode and update it manually.

On Windows use the VMware Microcode installer and download the microcode from
Intel and use that to update the Microcode on your machine.

On Windows you'll need to edit cpumcupdate.inf to remove the AMD microcode
files if you don't want to download the microcode from both vendors since the
VMware tool needs both to work properly.

Microcode update from Intel:
[https://downloadcenter.intel.com/download/27431/Linux-
Proces...](https://downloadcenter.intel.com/download/27431/Linux-Processor-
Microcode-Data-File?v=t)

VMware Microcode Installer: [https://labs.vmware.com/flings/vmware-cpu-
microcode-update-d...](https://labs.vmware.com/flings/vmware-cpu-microcode-
update-driver)

~~~
biaachmonkie
I tried this and have the driver installed and the Get-
SpeculationControlSettings Powershell module reports hardware support now. But
I can't get windows to enable support, I've tried setting the registry keys in
the referenced KB article
[https://support.microsoft.com/help/4073119](https://support.microsoft.com/help/4073119)

I suspect that the driver loads to late, that windows has already done it's
check to enable support before the driver loads the microcode update and I
can't find anything about re-running the check or anyway to load the driver
before that check.

Output from Get-SpeculationControlSettings Powershell module

    
    
        ---
        
        Speculation control settings for CVE-2017-5715 [branch target injection]
        
        Hardware support for branch target injection mitigation is present: True
        Windows OS support for branch target injection mitigation is present: True
        Windows OS support for branch target injection mitigation is enabled: False
        Windows OS support for branch target injection mitigation is disabled by system policy: False
        Windows OS support for branch target injection mitigation is disabled by absence of hardware support: False
        
        Speculation control settings for CVE-2017-5754 [rogue data cache load]
        
        Hardware requires kernel VA shadowing: True
        Windows OS support for kernel VA shadow is present: True
        Windows OS support for kernel VA shadow is enabled: True
        Windows OS support for PCID performance optimization is enabled: True [not required for security]
        
        Suggested actions
        
        * Follow the guidance for enabling Windows Client support for speculation control mitigations described in https://support.microsoft.com/help/4073119
        
        BTIHardwarePresent             : True
        BTIWindowsSupportPresent       : True
        BTIWindowsSupportEnabled       : False
        BTIDisabledBySystemPolicy      : False
        BTIDisabledByNoHardwareSupport : False
        KVAShadowRequired              : True
        KVAShadowWindowsSupportPresent : True
        KVAShadowWindowsSupportEnabled : True
        KVAShadowPcidEnabled           : True

~~~
dogma1138
That is strange what CPU/OS combo? this worked on my desktop and laptop, try
rolling back the Jan 2018 update and then push it again with the new microcode
there shouldn't be any difference the OS reads the microcode either from it's
own partition or from the UEFI partition (BIOS) which ever is newer is used.

------
imron
Didn't mention anything about how it would have been a good idea to sell all
your stock 2 weeks ago.

------
bemeurer
"There has been a disturbance in the kitchen..."

------
politelemon
The smug face you see there, friends, is that of a man with 39 million reasons
not to care about this security-first pledge which someone else wrote.

~~~
dang
Please don't post rage rants to HN, regardless of how you feel about someone
or how their company did a thing you don't like. You may not owe better to the
CEO of Intel, but you owe better to this community if you want to keep
commenting here.

~~~
politelemon
You are right, my apologies. I don't think deleting comments is allowed but
I'll keep this in mind in the future

~~~
dang
Appreciated!

