Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Responds to Security Research Findings

newsroom.intel.com

Post reply on HN
Print view View original

211–220 of 245 posts

Re: Intel Responds to Security Research Findings

#211

Post by BuildTheRobots »

arghwhat wrote: post #187
noncoml wrote: post #168

Earlier quoted context omitted.

> This is deceptive. It immediately mentions AMD to give the impression that AMD also suffer from the problem. It looks like (some?) AMD processors might be affected as well: "These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."[1] [1] https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...

From what I can gather, one of the 3 issues found is Intel-only, very bad and very easy to exploit, and can be patched with a large performance hit. Another is harder to exploit, and has no known workaround (likely requiring new silicon to fix), and affects basically all micro-architectures in use today, including AMD's x86 silicon. The third, I know nothing of.

Ah, it must be serious, there's now a branded website [1] for it ;)

I believe the Intel only issue is called "Meltdown" and the second is called "Spectre"; the attack website [1] has details of both.

[1] https://meltdownattack.com/

Re: Intel Responds to Security Research Findings

#212

Post by tedivm »

mehrdadn wrote: post #205
redcalx wrote: post #164

Earlier quoted context omitted.

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.

> It's kind of semantics though isn't it? I never understood how this sentence became a defense. Yes, yes it is. It is semantics. Everything is semantics. The difference between getting fired and getting laid off is semantics, and everybody cares about it and recognizes it. The difference between "I'll pick you up at 5pm" and "I promise I will pick you up at 5pm even if my car breaks down and the train gets derailed"…

Since we're being semantic about things, lets be clear that when someone says it's all "semantics" they mean that the person is engaging in a semantic dispute. This is a type of argument that has a specific meaning-

> A semantic dispute is a disagreement that arises if the parties involved disagree about the definition of a word or phrase, not because they disagree on material facts, but rather because they disagree on the definitions of a word (or several words) essential to formulating the claim at issue.

When someone is "arguing semantics" they are often trying to obfuscate the original issue being discussed.

In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them. redcalx is then stating the general definition of "bug" in an attempt to point out how limiting and nonstandard their definition is.

Re: Intel Responds to Security Research Findings

#213

Post by nebulous1 »

mehrdadn wrote: post #207
nebulous1 wrote: post #203

Earlier quoted context omitted.

So it's your contention that Intel never guaranteed that ring 0 protected memory couldn't be read by code running in ring 3, thereby rendering the concept of memory read protection useless by design?

> So it's your contention that Intel never guaranteed that ring 0 protected memory couldn't be read by code running in ring 3. Assuming by "read" you mean "inferred", yes, I'm not aware of any such guarantee, but again, I of course have't read everything they have published, so by all means prove me wrong.

Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A 4-30

  4.6.1 Determination of Access Rights

  For user-mode accesses:
  — Data reads.
  Access rights depend on the mode of the linear address:
    ...
    • Data may not be read from any supervisor-mode address.

Re: Intel Responds to Security Research Findings

#214

Post by mehrdadn »

nebulous1 wrote: post #213
mehrdadn wrote: post #207

Earlier quoted context omitted.

> So it's your contention that Intel never guaranteed that ring 0 protected memory couldn't be read by code running in ring 3. Assuming by "read" you mean "inferred", yes, I'm not aware of any such guarantee, but again, I of course have't read everything they have published, so by all means prove me wrong.

Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A 4-30 4.6.1 Determination of Access Rights For user-mode accesses: — Data reads. Access rights depend on the mode of the linear address: ... • Data may not be read from any supervisor-mode address.

And this contradicts the above how, exactly?

Re: Intel Responds to Security Research Findings

#215

Post by nebulous1 »

nebulous1 wrote: post #213
mehrdadn wrote: post #207

Earlier quoted context omitted.

> So it's your contention that Intel never guaranteed that ring 0 protected memory couldn't be read by code running in ring 3. Assuming by "read" you mean "inferred", yes, I'm not aware of any such guarantee, but again, I of course have't read everything they have published, so by all means prove me wrong.

Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A 4-30 4.6.1 Determination of Access Rights For user-mode accesses: — Data reads. Access rights depend on the mode of the linear address: ... • Data may not be read from any supervisor-mode address.

> And this contradicts the above how, exactly?

Documentation: Data may not be read from any supervisor-mode address.

Published vulnerability: Data may be read from any supervisor-mode address.

Re: Intel Responds to Security Research Findings

#216

Post by mehrdadn »

tedivm wrote: post #212
mehrdadn wrote: post #205

Earlier quoted context omitted.

> It's kind of semantics though isn't it? I never understood how this sentence became a defense. Yes, yes it is. It is semantics. Everything is semantics. The difference between getting fired and getting laid off is semantics, and everybody cares about it and recognizes it. The difference between "I'll pick you up at 5pm" and "I promise I will pick you up at 5pm even if my car breaks down and the train gets derailed"…

Since we're being semantic about things, lets be clear that when someone says it's all "semantics" they mean that the person is engaging in a semantic dispute. This is a type of argument that has a specific meaning- > A semantic dispute is a disagreement that arises if the parties involved disagree about the definition of a word or phrase, not because they disagree on material facts, but rather because they disagree…

> When someone is "arguing semantics" they are often trying to obfuscate the original issue being discussed.

Well (and the irony is not lost on me here), this wasn't part of the definition of a semantic dispute that you just presumably quoted... it was just something you tacked onto it afterward. And the entire problem is that to you a semantic dispute might imply the original issue is being obfuscated, whereas to the other person it might imply you are trying to stretch your own ideas to where they wouldn't apply.

Read your own definition: you said a semantic dispute is when they disagree on essential words. Not fluff words. People don't need to disagree on facts to have legitimate disagreements about about their interpretations and consequences. We all agree the CPU behaved in an undesirable way. There is no debate there, but that fact was insufficient to get us anywhere. What we disagree on is whether that is a "bug", which matters to all sides because it has consequences as who is to resolve the issue and how.

> In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them.

[Edit: I misread part of the comment here; see below.]

If it's "unintended behavior", then, sure, the CPU has "bugs", but that's a pretty useless definition that gets you nowhere (especially legally). If it's "does not perform as specified", which at least to me is a more logical choice, then I'm afraid I have not seen a shred of evidence that they ever claimed memory contents are immune from CPU timing/cache/etc. effects.

Re: Intel Responds to Security Research Findings

#217

Post by 13of40 »

haberman wrote: post #177
redcalx wrote: post #164

Earlier quoted context omitted.

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.

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 t…

I was about to say something like, "Well, in a broad sense they introduced protection features to x86 to prevent modification or disclosure of memory contents across process boundaries...and that's broken, therefore bug."

However, looking at the reference manual for the 80386 [1], and a modern version of their x64 manual [2], they don't actually say it's for security:

Original: "6.1 Why Protection? The purpose of the protection features of the 80386 is to help detect and identify bugs. The 80386 supports sophisticated applications that may consist of hundreds or thousands of program modules..."

Modern: "The IA-32 architecture’s protection mechanism recognizes four privilege levels, numbered from 0 to 3, where a greater number mean less privilege. The reason to use privilege levels is to improve the reliability of operating systems."

So it's more like someone sells you a box with a lock on the front that looks a lot like a safe and all of the individual hinges and pins and whatnot are guaranteed to some degree, but they never actually say it's OK to lock your stuff inside.

[1]https://css.csail.mit.edu/6.858/2013/readings/i386.pdf

[2]https://www.intel.com/content/www/us/en/architecture-and-tec...

Re: Intel Responds to Security Research Findings

#218

Post by tedivm »

mehrdadn wrote: post #216
tedivm wrote: post #212

Earlier quoted context omitted.

Since we're being semantic about things, lets be clear that when someone says it's all "semantics" they mean that the person is engaging in a semantic dispute. This is a type of argument that has a specific meaning- > A semantic dispute is a disagreement that arises if the parties involved disagree about the definition of a word or phrase, not because they disagree on material facts, but rather because they disagree…

> When someone is "arguing semantics" they are often trying to obfuscate the original issue being discussed. Well (and the irony is not lost on me here), this wasn't part of the definition of a semantic dispute that you just presumably quoted... it was just something you tacked onto it afterward. And the entire problem is that to you a semantic dispute might imply the original issue is being obfuscated, whereas to th…

> ...you cannot seriously expect this to be a convincing argument without offering your own kosher definition (read: semantics) of "bug".

It's kind of hilarious that the only reason you can claim this is because of your selective editing. The whole statement you are responding too is this-

> In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them. redcalx is then stating the general definition of "bug" in an attempt to point out how limiting and nonstandard their definition is.

Since you missed it the first time redcalx is already making the argument for me. I don't need to supply a separate version of the definition, I just need you to read the original message you were responding too.

Re: Intel Responds to Security Research Findings

#219

Post by Danihan »

bjornedstrom wrote: post #73

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 operat…

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

Unless you view a key or password... then use it to corrupt, modify or delete data.

Re: Intel Responds to Security Research Findings

#220

Post by droopybuns »

bjornedstrom wrote: post #73

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 operat…

I feel like a lot of really smart people are really naive about public relations.

PR exists to protect the company from the masses and the lawyers. We in the tech community should not waste time personalizing a response to pr communications. We are not the target market. It is the general public and politicians they are trying to persuade. If they ameliorate them, they win and can move on to the next fight.

They will play word games and fiddle with language. It is not worth responding to PR if you deeply understand the problem. You will only find problematic statements. You will never get satisfaction because satisfying the technical community is a fundamental error for anyone who knows what they are doing in public relations.

There are other venues for us. Patch notes and tech forums are worthy of your time.

Post reply on HN