
Intel Responds to Security Research Findings - runesoerensen
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
======
bjornedstrom
This is probably one of the poorest and most defensive PR pieces I've read
from a company in a long time, and it does not really make me sympathetic to
them at all.

> Intel and other technology companies have been made aware of new security
> research describing software analysis methods that, when used for malicious
> purposes, have the potential to improperly gather sensitive data from
> computing devices that are operating as designed. Intel believes these
> exploits do not have the potential to corrupt, modify or delete data.

This is deceptive. It very quickly acknowledge the confidentiality aspect, but
then claims that is "operating as designed" and then immediacy try to damage
control by pointing out what the exploits cannot do (corrupt/modify/delete).

> Recent reports that these exploits are caused by a “bug” or a “flaw” and are
> unique to Intel products are incorrect. Based on the analysis to date, many
> types of computing devices — with many different vendors’ processors and
> operating systems — are susceptible to these exploits.

This is deceptive. In the first sentence it combines two statements: 1)
bug/flaw in Intel products and 2) that it is unique to Intel. In the rest of
the paragraph it then claims that the previous statements are incorrect, but
only addressing the second point.

> Intel is committed to product and customer security and is working closely
> with many other technology companies, including AMD, ARM Holdings and
> several operating system vendors, to develop an industry-wide approach to
> resolve this issue promptly and constructively. Intel has begun providing
> software and firmware updates to mitigate these exploits. Contrary to some
> reports, any performance impacts are workload-dependent, and, for the
> average computer user, should not be significant and will be mitigated over
> time.

This is deceptive. It immediately mentions AMD to give the impression that AMD
also suffer from the problem.

It then goes on with a straw man about performance impacts ("contrary to some
reports").

And then mentions "average computer user" whereas the real problem is
obviously not average computer users. Again, deceptive.

~~~
haberman
I could be wrong, but I take the "bug/flaw" language to mean this: the
processor is doing exactly what it was designed to do (unlike the Pentium FDIV
bug, for example). A new class of exploit was recently discovered, and these
CPUs are vulnerable to this new exploit. But there was no bug in how these
CPUs were implemented, and the only design flaw is that they failed to
withstand a new class of exploit that was not known at the time they were
designed.

(I don't have any information that could confirm/deny this, it's just how I
interpret their verbiage).

I don't get the sense that they are trying to deceptively contradict only part
of the previous statement.

~~~
redcalx
It's kind of semantics though isn't it? If I write a piece of software that
follows the spec and fulfils the customer's need, but then someone tries to do
something with it that we hadn't thought of and that results in a security
hole... around here we call that a bug, a flaw, something we missed. Maybe
it's reasonable to have not spotted the bug, but that wouldn't make it not a
bug/flaw.

~~~
haberman
Yeah I agree there is a line there somewhere. If someone sells you a safe and
it can be opened with a ballpoint pen, that seems like a flaw. If someone
sells you a safe and it can be opened with a military grade laser, that's sort
of expected. If someone sells you a safe and it can be opened with a cheap
consumer gadget, but that gadget is complex and was unforeseen when the safe
was designed, what do you say about that? The last one seems like the closest
analogy.

Another example: would you say that MD5 is buggy/flawed?

I guess overall I think this is fair to call a "flaw" but not a "bug."

~~~
redcalx
> I guess overall I think this is fair to call a "flaw" but not a "bug."

Yes I agree, it's not a bug in the sense of a silly mistake that slipped
through development and testing. It's a flaw / attack-vector that no-one
thought of... until now.

~~~
zde
Reminds me of dieselgate. "Our product is ok unless operated out of spec"
didn't work, iirc.

------
AshleysBrain
> Intel believes these exploits do not have the potential to corrupt, modify
> or delete data.

Reading from kernel memory [edit: from unprivileged apps] is still a severe
security issue though, right? This sounds like they're trying to downplay that
hard, especially with the "operating as designed" phrase.

> Recent reports that these exploits are caused by a “bug” or a “flaw”

[Unprivileged] reading from kernel memory is something of a flaw, no? Fair
point about not being Intel specific though.

> any performance impacts are workload-dependent, and, for the average
> computer user, should not be significant

Hearing echos of Intel's early FDIV response along the lines of "the average
computer user doesn't need perfectly accurate division"...

> However, Intel is making this statement today because of the current
> inaccurate media reports.

This and similar sentences has a strange tone to me, it sounds almost grumpy.
I guess it got rushed out.

~~~
Nition
That "bug" or "flaw" sentence is very carefully worded. It's like:

    
    
        bool bug = true;
        bool flaw = true;
        bool uniqueToIntel = false;
    
        bool reportsAreTrue = (bug || flaw) && uniqueToIntel;
    
        // reportsAreTrue == false!

~~~
redcalx
Yes it's designed in such a way that in a court of law they could claim they
were announcing a bug, but most or many people reading it would come to the
opposite conclusion. In other words it's deceptive.

------
smcleod
What a scummy, dishonest response.

\- Saying it's not a 'bug' or 'flaw' = lie.

\- Cold naming AMD and ARM in the post, I'm certain not just to throw their
names in the ring but also for SEO ranking and relationships.

\- Failing to address the root cause, how it came to be and provide other
technical references.

And let's not forget - Intel's CEO sold his stock.

\--

* Note: "AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a "near zero risk to AMD processors at this time." British chipmaker ARM told news site Axios prior to this report that some of its processors, including its Cortex-A chips, are affected." \- [http://www.zdnet.com/article/security-flaws-affect-every-int...](http://www.zdnet.com/article/security-flaws-affect-every-intel-chip-since-1995-arm-processors-vulnerable/)

------
rpns
It comes across as fairly defensive. Presumably the statement was hastily put
together, but it's not really the tone you want to strike when you have a lot
of worried customers wondering what is going on.

> Intel believes its products are the most secure in the world and that, with
> the support of its partners, the current solutions to this issue provide the
> best possible security for its customers.

A rather bizarre statement of nothingness, and also an odd thing to say in a
statement that just named AMD and ARM.

> Contrary to some reports, any performance impacts are workload-dependent,
> and, for the average computer user, should not be significant and will be
> mitigated over time.

It's interesting to note what it doesn't say – as it would seem to imply that
for some workloads the performance impact will be significant.

~~~
qubex
“Workload dependent” clearly implies (despite the spin they are trying to put
on it) that some users will be worse off than others. What isn’t my at all
clear (to me) is what they mean by ”will be mitigated over time”. Are they
implying that when we buy new professors (from them) there’ll be a hardware
fix that won’t require the performance-sapping patch?

Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns
out that AMD chips are immune to the flaw.

~~~
mywittyname
> Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it
> turns out that AMD chips are immune to the flaw.

The official fix for this in the Linux kernel has a comment that literally
says to assume all x86 processors suffer from the same issue and will disable
KPTI for all x86 processors, including AMD.

There's an AMD-specific patch that I saw floating around that keeps the
setting enabled for AMD processors, but I'm not sure if it made it into the
mainline.

~~~
qubex
I don't know if it's possible to see who contributed that patch (yet), but I’m
cynical enough to half-expect that the “assume all x86 processors are
insecure” patch might come from an Intel engineer...

~~~
mywittyname
I would not be surprised at all, considering the patch I saw for the AMD
processors was literally a one-line if statement around the set cpu insecure
flag that added a check for AMD processors.

Google is failing me or I'd post a link.

------
ejcx
Lots of people being critical of this response. I think it's pretty good, and
have been on the disclosing side of this equation many times.

Admits responsibility and says their current course of action (working with
key stakeholders). Addresses concerns of the workaround. Has a timeframe for
future updates. Has a call to action for what you should be doing next. To
those of you pointing out that this is PR, you're right but that's not a
problem...

Short and sweet and has it all. If anything, it is a day late but monstrous
organizations probably had a lot of bureaucracy to cut through.

People are so reactionary and quick to throw any company with a security issue
under the bus, without ever having been on the other side of the table. The
reality is issues happen to everyone and Intel wants to fix it.

~~~
Jyaif
It's also manipulative, mentioning AMD and ARM for no other reason to make
people think those also have the flaw.

~~~
davesque
ARM may have a flaw:
[https://lwn.net/Articles/740393/](https://lwn.net/Articles/740393/)

------
mabbo
> Based on the analysis to date, many types of computing devices — with many
> different vendors’ processors and operating systems — are susceptible to
> these exploits.

Yes, many. Not your biggest competitor though, AMD. They're fine. And that may
be the point you're trying to downplay here.

> Intel believes its products are the most secure in the world

Again, your biggest competitor, AMD, does not have this flaw. So precisely how
is Intel the 'most secure in the world' if your biggest competitor is more
secure than you?

The title of this post should be 'Intel _PR_ Responds to Security Research
Findings'.

------
mistercow
It's always interesting when you see a damage control statement that basically
boils down to "contrary to what you may have heard, <exactly the same caveats
you've already heard>". It's a subtle kind of straw man, where you reassure
your audience by listing the same mitigating facts they've already heard, but
act as if those facts have been previously omitted.

I guess the goal is to produce the affect of reassurance when you don't
actually have any substantive reassurance to offer. I wonder if this works, in
general? My sense is that it always smells like bullshit, but I wouldn't
necessarily recall instances where it didn't.

------
2trill2spill
> Recent reports that these exploits are caused by a “bug” or a “flaw” and are
> unique to Intel products are incorrect.

Isn't the quote above which is from the Intel press release a blatant lie? All
the articles I have seen say this only affects Intel processors. Not AMD
processors nor, ARM, MIPS, SPARC or PowerPC chips. Did I miss something or is
Intel lying in it's press release.

~~~
thehardsphere
We won't know until we know what the actual bug is. All we know is that people
are writing patches for Intel chips, and what those patches do.

It's very possible that other processors are affected by the same issue in
some different way that doesn't require this set of patches to mitigate.

~~~
betterunix2
We know that AMD is not affected:

[https://lkml.org/lkml/2017/12/27/2](https://lkml.org/lkml/2017/12/27/2)

~~~
thehardsphere
We know that "AMD processors are not subject to the types of attacks that the
kernel page table isolation feature protects against." E.g. that AMD does not
need the patch that Intel does. That is not the same as saying AMD is not
affected at all.

We do not know what the actual bug that prompted this activity is. Nobody has
revealed that information. It is possible that the bug affects AMD also but
does not require this patch.

~~~
betterunix2
The followup sentence: "The AMD microarchitecture does not allow memory
references, including speculative references, that access higher privileged
data when running in a lesser privileged mode when that access would result in
a page fault."

That is a pretty specific reference to the root of the problem, and a pretty
clear indication that AMD's design decisions protect against whatever the
attack is. Sure, we may find out that there is more to the attack than just
speculative memory references, but so far what we have seen suggests a fairly
specific vulnerability (that just happens to involve the particular design
choices of a dominant chipmaker).

~~~
thehardsphere
And, 17 hours later, we now know that there were three distinct
vulnerabilities, of which one applies to AMD.

[https://googleprojectzero.blogspot.com/2018/01/reading-
privi...](https://googleprojectzero.blogspot.com/2018/01/reading-privileged-
memory-with-side.html)

~~~
betterunix2
Only under specific software configurations that are not enabled by default,
or confined to a userspace single process (which is bad for web browsers
running Javascript but not nearly as bad as the Intel-specific attacks). So
while AMD is somewhat vulnerable, the most severe and easiest to exploit
vulnerabilities are pretty specific to Intel. In a pedantic sense you were
right, AMD chips are _affected_ , but it is literally not on the same level as
for Intel chips.

------
myth_buster

      Intel believes these exploits do not have the potential to corrupt, 
      modify or delete data.
    

Followed by...

    
    
      Check with your operating system vendor or system manufacturer 
      and apply any available updates as soon as they are available.
    

This press release is a minefield. There are whole paragraphs devoted to say
nothing.

~~~
vhold
Somebody please correct me if I'm wrong, but I believe they're basically
saying "These exploits _do_ have the potential to read data."

~~~
int0x80
There are not saying it explicitly, which they should.

~~~
IshKebab
Yeah, sort of "Don't worry I'm not going to shoot you in the torso, arms or
legs."

------
brndnmtthws
> Contrary to some reports, any performance impacts are workload-dependent,
> and, for the average computer user, should not be significant and will be
> mitigated over time.

Given the lack of any facts, evidence, or details in the press release, how is
anyone supposed to take Intel seriously?

~~~
thezilch
Devils advocate.

Workload dependence... average user... not significant:

A lot of users probably see "30%" and will assume the worst. There really
isn't a lot of evidence of how much an average consumer will be affected.
Pretty sure your average consumer isn't running pgbench all day. Hell, I'm
willing to bargain 90% of servers (I really want to say more) are over-
provisioned by 30% or more.

Mitigated over time:

Kernels are getting out safe patches ASAP, performance be damned. With more
time to be careful, performance can be clawed back. And/or CPUs are upgrade
and features such as PCID mitigate perf losses.

~~~
teilo
The problem is that "average users" pointedly does _not_ include server and DB
admins. I don't know about anyone else, but that's what I'm sweating over. We
already know high I/O is what takes the biggest hit. I want to know what kind
of a hit I can expect on our MSSQL VMs, and I am pretty sure the answer is not
"minimal."

~~~
deadshift
If you're running SQL in a VM ... I'm pretty sure I know how to improve your
performance by 30%.

~~~
teilo
If you mean run on bare metal, not happening, due to MSFT's outrageous core
pricing model. They force you to license every core available to the OS,
whether you need the capacity or not. Running in a VM is the only way of
getting around that requirement.

If you mean run something other than MSSQL — also not happening. Vendor lock
in.

------
mannykannot
Interesting use of language:

'Recent reports that these exploits... are unique to Intel products are
incorrect... Intel is committed to product and customer security and is
working closely with many other technology companies, including AMD...'

Someone new to the issue might think AMD also has this problem.

Similarly (replacing the first elision in the above quote):

'Recent reports that these exploits are caused by a “bug” or a “flaw”... are
incorrect.'

So, working just the way you want it to, eh, Intel? But then, why would you
describe them as exploits?

~~~
thezilch
Not defending Intel here, but devils advocate...

You will find many clients asking how to disable, for example, the Linux
patch. Linux is releasing with a flag to disable it, so there is some merit.
Why would you want that? There are a lot of times you trust everything running
on your box and don't need to take the perf hit.

Intel (and possibly other archs/families) found a perf win that ends up having
security implications. A perf nonetheless. If you're willing to bet on your
userspace not reading kernel pages, does Intel have a feature for you!

~~~
mannykannot
Intel is certainly entitled to make and promulgate an objective assessment of
the impact of the problem, but a problem is still a problem even if it doesn't
affect everyone.

~~~
thezilch
Who says they won't?

The issue is embargoed, but that's, as usual, not keeping everyone from
speculating. That's fine too, but also realize the layman (even people in this
thread) is getting pummeled with ideas like "my new laptop is going to be 30%
slower tomorrow; WTF!!!"

~~~
mannykannot
> Who says they won't?

Not me. My comments are restricted to certain things Intel _did_ choose to
say.

And as you are concerned about rumor and disinformation, I cannot imagine you
are pleased with Intel's insinuation that AMD processors are also affected.

UPDATE: It seems AMD may be being misleading in this case...

------
rhema
>Recent reports that these exploits are caused by a “bug” or a “flaw” and are
unique to Intel products are incorrect.

From the English, this report makes it seems like there was no bug and no
flaw. However, they say that ((bug || flaw) && only_intel) is false, but I
have seen that AMD was not impacted.

Seems like this is a bug or flaw, since they are addressing it soon. They make
it seem like everyone should be working in the same boat to address this, but
they are just trying to un-distance themselves from their competition.

~~~
bonzini
> since they are addressing it soon. They make it seem like everyone should be
> working in the same boat to address this

I can assure you that indeed "everyone is working in the same boat to address
this", and has been doing so for months, across multiple OS and processor
vendors. It's already public that Microsoft and Apple have also implemented
page table isolation, and certainly Intel didn't name-drop AMD and ARM
carelessly in the press release.

~~~
lettergram
> and certainly Intel didn't name-drop AMD and ARM carelessly in the press
> release.

I'm sure it wasn't careless, but they are (from all accounts I have read)
blatantly lying. Intel isn't known for above board practices. They will do
what it takes to win - period.

Name dropping their competitors (to me), honestly shows me how dire of a
situation this is. If it wasn't, they wouldn't feel the need to defend
themselves and say, "well look at everyone else".

~~~
kunday
According to project zero report, a lot more than intel CPU's are affected by
this issue. See relavant HN post here

"These vulnerabilities affect many CPUs, including those from AMD, ARM, and
Intel, as well as the devices and operating systems running them."

[https://news.ycombinator.com/item?id=16065845](https://news.ycombinator.com/item?id=16065845)

------
colanderman
> Intel believes these exploits do not have the potential to corrupt, modify
> or delete data.

No, but they _do_ have the potential for privilege escalation or credential
exfiltration, which in turn _do_ grant the potential to corrupt, modify and
delete data.

------
mrmondo
Oh god, it's got a logo:
[https://meltdownattack.com](https://meltdownattack.com)

"Which systems are affected by Meltdown?

Desktop, Laptop, and Cloud computers may be affected by Meltdown. More
technically, every Intel processor which implements out-of-order execution is
potentially affected, which is effectively every processor since 1995 (except
Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on
Intel processor generations released as early as 2011. Currently, we have only
verified Meltdown on Intel processors. At the moment, it is unclear whether
ARM and AMD processors are also affected by Meltdown.

Which systems are affected by Spectre?

Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers,
as well as Smartphones. More specifically, all modern processors capable of
keeping many instructions in flight are potentially vulnerable. In particular,
we have verified Spectre on Intel, AMD, and ARM processors."

------
dmitrygr
> Intel believes these exploits do not have the

> potential to corrupt, modify or delete data.

That's strange, because I am pretty damn sure that with a working
read_kernel_byte(u64 addr) primitive, I can gather enough info to corrupt,
modify, or delete a lot of things.

------
makecheck
Something “operating as designed”, if designed incorrectly, is still broken.

Something that doesn’t “corrupt, modify or delete data” but _does_ “leak”
sensitive data to potential attackers, is still a serious exploit.

This is worryingly full of error-by-omission statements.

------
resoluteteeth
Seriously? Their response is "It's not fair! ARM made the same mistake so you
can't blame us!"?

------
wasx
Wow what a deceptive defensive response by intel. Nobody is concerned about
data being deleted, it's the unprivileged access thats the issue here.

------
robin_reala
> Intel and other vendors had planned to disclose this issue next week when
> more software and firmware updates will be available.

So coordinated patches to hit next week then.

------
zippie
Intel's investor call [1] is underway and they are describing the attack
vector(s). Rogue data load seems to be most concerning issue according to
Intel.

Intel thinks this will need firmware and operating system updates to fully
mitigate.

[1] [https://www.intc.com/investor-relations/investor-
education-a...](https://www.intc.com/investor-relations/investor-education-
and-news/investor-news/press-release-details/2018/Intel-Holds-Investor-Call-
Regarding-Security-Research-Findings/default.aspx)

------
alacombe
This is not a security report, this is PR.

Among other things, it implies, without explicitly naming them, that AMD, ARM
and OS vendors are being directly affected while most information out there
point out it's merely an Intel issue.

~~~
bjtitus
It does explicitly name them:

> Intel is committed to product and customer security and is working closely
> with many other technology companies, including AMD, ARM Holdings and
> several operating system vendors, to develop an industry-wide approach to
> resolve this issue promptly and constructively.

~~~
mynameisvlad
I think what the parent comment means is that they're explicitly named, but
not explicitly called out as being affected, just heavily implied.

------
cesarb
> Recent reports that these exploits are caused by a “bug” or a “flaw” and are
> unique to Intel products are incorrect.

A possible reading of "not a bug or a flaw" could be "works as designed", or
better, "works according to the spec". The spec probably never considered
cache timing side-channels (if that's what the issue is) as something to be
defended against.

------
rbanffy
Wouldn't it be wonderful if we could buy the latest Xeons at a 30% discount?
;-)

~~~
bkeroack
That's why they're the dominant player. Because even when a horrible defect is
exposed people still desire the product over the competition.

~~~
aceofspad4s
They would have to screw up really bad for people to go to AMD. I think that
may never happen.

~~~
rbanffy
People who need to get absolutely the most bang for the buck have no ties to
any given supplier. Cray deployed one of the first Opteron-based
supercomputers.

Intel got lots of datacenter business simply by having a better (as in "better
suited to our demands") product than anyone else in the segment. AMD has a
short time window to make some large sales. They have until Intel ships a
microcode fix or a new line of processors.

~~~
AsyncAwait
> They have until Intel ships a microcode fix

Sounds like microcode fix isn't possible.

~~~
rbanffy
Then the next generation it is.

It's a 5-30% performance boost without even a major change. :-(

------
runesoerensen
Project Zero has published a detailed writeup on this. It's worth noting (in
the context of Intel's response) that the P0 post confirms that AMD and ARM
CPUs are also affected:

 _" Variants of this issue are known to affect many modern processors,
including certain processors by Intel, AMD and ARM. For a few Intel and AMD
CPU models, we have exploits that work against real software. We reported this
issue to Intel, AMD and ARM on 2017-06-01"_

[https://googleprojectzero.blogspot.com/2018/01/reading-
privi...](https://googleprojectzero.blogspot.com/2018/01/reading-privileged-
memory-with-side.html)

Edit: Discussion
[https://news.ycombinator.com/item?id=16065845](https://news.ycombinator.com/item?id=16065845)

------
monocasa
Do we know the actual bug yet? I sort of assumed it was a timing attack on
KASLR rather than a leak of traditional kernel data.

Although I guess that there would have been cheaper mitigations like mapping
an empty page to all of the other KASLR slots rather than doing a full world
switch in that case...

~~~
AshleysBrain
It's true nobody knows what the actual bug is, but I was working with what Ars
Technica described: "If the problem were just that it enabled the
derandomization of ASLR, this probably wouldn't be a huge disaster... The
industry reaction... suggests that it's not just ASLR that's defeated and that
a more general ability to leak information from the kernel has been
developed." [https://arstechnica.com/gadgets/2018/01/whats-behind-the-
int...](https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-
flaw-forcing-numerous-patches/)

~~~
monocasa
I guess I've stopped reading security articles by Peter Bright ever since he
spent a whole series of articles shitting on project zero for disclosing
vulnerabilities after the 90 day disclosure window when Microsoft had just
been sitting on the bug.

[https://arstechnica.com/information-
technology/2015/01/googl...](https://arstechnica.com/information-
technology/2015/01/google-drops-more-windows-0-days-somethings-gotta-give/)

------
fermienrico
Additional information (PDF)[1] released as part of the Investor relations
call[2] today:

[1][https://s21.q4cdn.com/600692695/files/doc_presentations/2018...](https://s21.q4cdn.com/600692695/files/doc_presentations/2018/Side-
Channel-Analysis-Security.pdf)

[2][https://www.intc.com/investor-relations/investor-
education-a...](https://www.intc.com/investor-relations/investor-education-
and-news/investor-news/press-release-details/2018/Intel-Holds-Investor-Call-
Regarding-Security-Research-Findings/default.aspx)

------
quadyeast
"Recent reports that these exploits are caused by a “bug” or a “flaw” and are
unique to Intel products are incorrect."

The 'and' in this sentence makes this assertion correct and is very deceptive.

------
gadders
The Register translation of the Intel spin is quite amusing:

[https://www.theregister.co.uk/2018/01/04/intels_spin_the_reg...](https://www.theregister.co.uk/2018/01/04/intels_spin_the_registers_annotations/)

------
krschultz
This fails all 3 points on Scott Galloway's checklist of how to respond to a
crisis. [https://www.youtube.com/watch?v=PB-
AyvgE8Ns](https://www.youtube.com/watch?v=PB-AyvgE8Ns)

------
jaydestro
this is a denial from PR and a poor one at that.

------
Havoc
What a strange response.

>many types of computing devices — with many different vendors’ processors

Really? Like who?

------
nurettin
This probably means software is using CPUs in a way that they weren't meant
to. To me, it is funny to watch how virtualization and JIT compilers changed
the game for CPU vendors who were used to making CPUs mainly for compiling and
running software on a single host instance. Since we have direct
virtualization support now, I suspect we are going to get a JIT support in
CPUs soon (if we didn't already).

------
GenericsMotors
> Intel believes its products are the most secure in the world and that, with
> the support of its partners, the current solutions to this issue provide the
> best possible security for its customers.

* _sad trombone_ *

They're obviously not the most secure, as the Project Zero research shows. The
whole press release has to be one of the most dismissive and snobbish PR
pieces I've seen from a large corp.

------
CiPHPerCoder
> Intel is committed to the industry best practice of responsible disclosure
> of potential security issues

No, the industry best practice is _coordinated disclosure_. The term
"responsible disclosure" is a misnomer that we'd be far better off if we, as a
society, stopped using it.

[https://adamcaudill.com/2015/11/19/responsible-disclosure-
is...](https://adamcaudill.com/2015/11/19/responsible-disclosure-is-wrong/)

~~~
tedunangst
Do you think the executive speculation has been well coordinated? :)

------
dingo_bat
> Intel believes its products are the most secure in the world

Well, lol. It's a bit rich to say this in a vulnerability disclosure
statement.

------
electic
This is a good time to bring up Intel ME. It is a black box and has already
proven to have security issues. There maybe be more we do not know of. This
paging flaw is accidental however Intel ME is designed to have unfettered
control over all parts of the machine.

If Intel really believed in making secure products and believed in secure
computing, they would remove Intel ME.

------
thg
> Intel believes its products are the most secure in the world

[https://security-
center.intel.com/advisory.aspx?intelid=INTE...](https://security-
center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr)

~~~
aceofspad4s
"The most secure in the world" does not mean "flawless". Thinking like that is
pretty dangerous (and silly)

~~~
thg
I haven't seen any articles about AMD PSP security vulnerabilities yet, but
there's a new one about IME every other month. If Intel truly is the most
secure in the world, why are their CPUs riddled with security bugs big enough
to drive trains through (IME has de facto become a integral part of Intel
CPUs) and where are the news about non-Intel CPUs with similar bugs?

------
jchw
>Intel believes its products are the most secure in the world

After the Intel ME mess? I'm not so sure.

------
b1gtuna
If they believe it's not a threat, why the haste from the Kernel devs to fix
KAISER?

------
dmitriid
Corporate-speak -> human-speak:

\- Yes, the flow/bug exists

\- We don't yet know if it can be successfully exploited at scale.

\- It's quite possible that other CPU designs are affected as well, we don't
have concrete data though. AMD and ARM have already started looking into the
issue.

\- Patches will be coming from as many manufacturers and as many OS-vendors as
we can convince this is serious on a short notice.

\- The patches do affect performance, often significantly, but there's nothing
we can do in such a short period of time. We can only hope we can come up with
better solutions down the line.

------
valuearb
[https://www.youtube.com/watch?v=pdFl__NlOpA](https://www.youtube.com/watch?v=pdFl__NlOpA)

