More Intel speculative execution vulnerabilities

Post by Merrill » Wed, Nov 13, 2019, 12:45 PM UTC

segfaultbuserr wrote: post #31

wtallis wrote: post #13

Earlier quoted context omitted.

> This place is what Hewlett-Packard was probably like in 2000 (with the printer monopoly), the collapse is coming, but without starting over there is no way to fix it. Interestingly, that printer monopoly seems to be doing fine today, given how I have to go to hp.com to get drivers for my Samsung printer.

Hewlett-Packard was an electronic engineering, semiconductor, and computing company from the beginning (the first product they sold was an audio distortion analyzer, it used a creative circuit to achieve high performance at minimum cost), they used to do serious and innovative R&D. There were the glorious days when Hewlett-Packard makes state-of-art test equipment and semiconductor devices, developed in-house enterpr…

Post by segfaultbuserr » Wed, Nov 13, 2019, 12:54 PM UTC

jefftk wrote: post #92

segfaultbuserr wrote: post #84

Earlier quoted context omitted.

> a good capitalist would try to sell the discovery to the highest bidder. Not all security researchers are doing it for the money, 0day markets always exist. Malicious people who wish to use the vulnerability for profit wouldn't disclose the vulnerability to begin with. So it's not a new problem. > this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder wou…

If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading. Here's an example of Gotham City Research trying this approach and failing: https://www.thedrum.com/news/2017/09/21/criteo-counters-frau... (Not a lawyer)

Post by chooseaname » Wed, Nov 13, 2019, 12:55 PM UTC

Jonnax wrote: post #6

So Intel failed to mitigate the vulnerability when it was first reported. Then they extended the embargo from May until November. And they still didn't fix it. What's going on with Intel? Like they're going all in with lying in benchmarks against AMD and straight up forgetting what has been reported as security issues.

Post by segfaultbuserr » Wed, Nov 13, 2019, 1:04 PM UTC

segfaultbuserr wrote: post #71

xucheng wrote: post #52

> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, l…

Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything, just two or three additional unpatched PoCs with full source code would be enough. However, unlike buffer overflow exploits, most researches on CPUs are conducted within academic institutions, doing this certainly breaches the code of conduct. Also, CPUs are the most cr…

Post by zzzcpan » Wed, Nov 13, 2019, 1:12 PM UTC

wolf550e wrote: post #55

paulddraper wrote: post #29

Earlier quoted context omitted.

AFAIK Spectre variant 1 only applies to a single address space; i.e. per process. Processes are really "meant" to be the units of security (user, files, network, memory limit, etc.); it's reasonable to need different processes for security partitions.

There used to be a time when people thought relying on if statements for security was enough and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs. Now we know better. 1 - https://en.wikipedia.org/wiki/Singularity_(operating_system)