Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw • Hacker News Board

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#481

Post by mtanski » Wed, Jan 03, 2018, 10:33 PM UTC

kllrnohj wrote: post #449

mtanski wrote: post #383

Earlier quoted context omitted.

If you bypass the page cache you do not have read()/write() and mmap you avoid the syscall overhead. This matters a lot for high IOPs devices. Also these new fangled devices claim support word cache line sync using normal cpu flush instructions. Also avoiding fsync syscall.

One does not follow the other. Where are any references to how this will let you bypass read & write? User-space applications are still interacting with a filesystem, which they access via read/write and not a block device. There's no talk in the DAX information about how this results in a zero-syscall filesystem API, and I'm not seeing how that would ever work given there would then be zero protections on anything.…

Please re-read my above comment. There is no new API. The DAX userspace API is mmap.

This work is experimental but you can mmap a single file on a filesystem on this device using new DAX capabilities. Most access will not longer require a syscall.

This comes with all the usual semantics and trappings of mmap plus some additional caveats as to how the filesystem / DAX / hardware is implemented. Most reads/writes will not require a trip to the kernel using the normal read()/write() syscalls. Additionally, there is no RAM page cache baking this mmap instead the device is mapped directly at a virtual address (like DMA).

Finally, flush for these kinds of devices is at the block level implemented using normal instructions and not fsync. Flush is going to be done using the CLWB instruction. See: https://software.intel.com/en-us/blogs/2016/09/12/deprecate-...

LWN.net has lots of articles and links in their archives from 2016/2017. It's a really good read. Sadly I do not have time to dig more of them up for you. Do a search for site:lwn.net and search for DAX or MAP_DIRECT.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#482

Post by ktta » Wed, Jan 03, 2018, 10:39 PM UTC

zedpm wrote: post #388

ktta wrote: post #343

Earlier quoted context omitted.

>It's, however, really bad if you sell CPU cycles for a living. Who really sells CPU cycles? Cloud providers sell instances priced per core. So the real hit is by the customers since they have to shell out for more instances for the same amount of computing power. The hit I see is by providers of 'serverless' computing, since they charge per request and have their margins reduced.

> The hit I see is by providers of 'serverless' computing, since they charge per request and have their margins reduced. AWS, Azure, and GCP all bill serverless with a combination of per-request fees and compute (GB-seconds), so I'd expect the entire hit to be passed on to the user since this will cause increased compute time for each request. N requests that used to average 300ms each will now be N requests that ave…

I don't understand what exactly you're saying. All of those services have serverless services, but they also have server based instances which abstract compute to amount of cores and RAM rather than CPU cycles. And most use is out of the services which aren't serverless.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#483

Post by maxander » Wed, Jan 03, 2018, 10:43 PM UTC

dijit wrote: post #454

ajross wrote: post #323

Earlier quoted context omitted.

Very very few highly tuned "peak performance" workloads are dominated by syscall overhead like the test that produced that 30% number was. It's best to hold off on the hyperbole.

I have a power dependent workload that scales horizontally and is currently already dominated by the cost of system calls. This will effectively, directly cause me to buy 30% more compute on a huge infrastructure. (2,000~physical machines. Quite beefy dual socket machines with a lot of memory) I know I’m not alone. Then again. Think of microservices, Kubernetes for instance; Network requests are system calls.

Will you be buying Intel-based machines? Or will you be running a hybrid-architecture cluster now?

I don’t know very much about computing on that scale, but I wonder if all the people selling off Intel stock are thinking this story through.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#484

Post by planteen » Wed, Jan 03, 2018, 10:45 PM UTC

kabdib wrote: post #235

spdy wrote: post #77

Earlier quoted context omitted.

Isn't why this problem even exits the exact opposite? Intel was losing on the mobile market and changed internal testing to iterate faster by cutting corners. Found a quote: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our comp…

Man, you should see the errata for some ARM-based SOCs. It's amazing that they work at all. Vendor, in conversation: "We're pretty sure we can make the next version do cache coherency correctly." Me (paraphrased): "Don't let the door hit you in the ass on the way out." Management chain chooses them anyway, I spend the next year chasing down cache-related bugs. Fun.

Yep. I've seen scary errata and had paranoid cache flushes in my code as a precaution.

My favorite ARM experience was where memcpy() was broken in an RTOS for "some cases". "some cases" turned out to be when the size of the copy wasn't a multiple of the cache line size. Scary stuff.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#485

Post by johncalvinyoung » Wed, Jan 03, 2018, 10:47 PM UTC

rincebrain wrote: post #462

rincebrain wrote: post #186

Earlier quoted context omitted.

The hypothesis I've seen, and why people seem to be rushing to patch it without explaining, is that you might be able to not only leak addresses, but actual data, from any ring, into unprivileged code, at which point, your security model is burned to the ground. AIUI, the present circumstances are: - there exists a public PoC from some researchers of side-channel leaking kernel address information into userland via J…

Addendum for anyone still reading: - Intel issued a press release saying they planned to announce this next week after more vendors had patched their shit, which lends me more cause to believe that the Xen bug might be the same one [1] - Intel claims in the same PR that "many types of computing devices — with many different vendors’ processors" are affected, so I'll be curious to see whether non-Intel platforms fall…

https://security.googleblog.com/2018/01/todays-cpu-vulnerabi... https://googleprojectzero.blogspot.com/2018/01/reading-privi...

Seems that Google/Project Zero felt the need to go ahead and break embargo. Worth adding to the above list of news sources.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#486

Post by johncalvinyoung » Wed, Jan 03, 2018, 10:52 PM UTC

rincebrain wrote: post #462

rincebrain wrote: post #186

Earlier quoted context omitted.

The hypothesis I've seen, and why people seem to be rushing to patch it without explaining, is that you might be able to not only leak addresses, but actual data, from any ring, into unprivileged code, at which point, your security model is burned to the ground. AIUI, the present circumstances are: - there exists a public PoC from some researchers of side-channel leaking kernel address information into userland via J…

Addendum for anyone still reading: - Intel issued a press release saying they planned to announce this next week after more vendors had patched their shit, which lends me more cause to believe that the Xen bug might be the same one [1] - Intel claims in the same PR that "many types of computing devices — with many different vendors’ processors" are affected, so I'll be curious to see whether non-Intel platforms fall…

Also from the P0 blog post: Variant 1: bounds check bypass (CVE-2017-5753) Variant 2: branch target injection (CVE-2017-5715) Variant 3: rogue data cache load (CVE-2017-5754)

My checking doesn't show any of those three explicitly listed in Apple's security updates up through 10.13.2/2017-002 Sierra.

https://support.apple.com/en-us/HT201222

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#487

Post by planteen » Wed, Jan 03, 2018, 10:52 PM UTC

ClassyJacket wrote: post #435

cdoxsey wrote: post #239

Earlier quoted context omitted.

If you run things efficiently you're eaking every ounce of performance out of this hardware. A 30% performance hit means a 30% cost increase. The bigger issue is for things that don't scale easily. That sql server that was at 90% capacity is suddenly unable to handle the load. Sure that could've happened organically, but now it happens (perhaps literally) overnight for everyone all at once. Expect a bunch of outages…

"A 30% performance hit means a 30% cost increase." Just wanna point out that a 30% performance hit means a 43% cost increase.

Yes. This is so often forgotten when talking about stock prices (which those 2x or 3x daily derivatives are so dangerous).

For those confused: the math here is a 30% decrease puts you at 70%. To go from 70% back to 100%, 30% only gets you to 91% (0.70*1.3). 1/0.7 = 1.43 means you need 43% to recover.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#488

Post by eropple » Wed, Jan 03, 2018, 11:01 PM UTC

anarazel wrote: post #465

eropple wrote: post #291

Earlier quoted context omitted.

I've seen that message. It acknowledges the same problems: do-nothing problems over a local unix socket. Real-world use cases introduce much more latency from other sources in the first place. I'm sticking with an expectation in the 2%-5% range.

> I've seen that message. It acknowledges the same problems: do-nothing problems over a local unix socket. The first set of numbers isn't actually unrealistic. Doing lots of primary key lookups over low latency links is fairly common. The "SELECT 1" benchmark obviously was just to show something close to the worst case.

> The first set of numbers isn't actually unrealistic. Doing lots of primary key lookups over low latency links is fairly common.

Latency through loopback on my machine takes 0.07ms. Latency to the machine sitting next to me is 5ms.

We're actually (and to think, today I trotted out that joke about what you call a group of nerds--a well, actually) talking multiple orders of magnitude through which kernel traps are being amplified.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#489

Post by partiallypro » Wed, Jan 03, 2018, 11:07 PM UTC

chx wrote: post #468

partiallypro wrote: post #461

Earlier quoted context omitted.

There is a 0% chance you could prove he sold for that reason. Also if you didn't notice the stock is only a few %pts from its ATH; and almost trading at the exact price he sold it at.

I have no idea what happens when the official security disclosure happens and the bugfixes get released. And what the SEC can prove and what they can't, I do not claim to be an authority of.

Intel and AMD were informed of the vulnerability in June. The stock is up significantly since then, if the CEO was selling for that reason you'd assume it would be much sooner after. In all likelihood this is for tax purposes. The SEC would likely never be able to prove otherwise. I also doubt the SEC even looks at it. There was heavy options volume leading into it though, which they might.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#490

Post by cookiecaper » Wed, Jan 03, 2018, 11:18 PM UTC

foldr wrote: post #460

cookiecaper wrote: post #274

Earlier quoted context omitted.

> They really dislike insider trading, it's one of the few things where even rich people can get imprisoned -- and the typical jail sentence has been steadily climbing up for decades now. Insider trading, like many white-collar crimes, exists primarily for its value as a weapon. There is nothing actually illegal about the act of selling a stock; it's all about casting aspirations as to intent and who-knew-what-when.…

Intent is a key component of most crimes, isn't it? https://en.wikipedia.org/wiki/Mens_rea

Disclaimer: I'm not a lawyer, there are definitely people who can explain this better, and I'm probably using these terms incorrectly.

Yes, mens rea is an important consideration, but it's nuanced. Check the Model Penal Code [0], which identifies four differing types of mens rea, including negligence and recklessness; that is, a "guilty mind" (mens rea), for criminal purposes, does not necessarily require what would be conventionally considered bona fide malice or intent to harm.

What I meant when I said an "enhancement" or "aggravating factor" is that usually you have an objectively asocial actus reus, like theft, and should mens rea come into play, it's generally a defensive thing seeking to exculpate the accused, as in "I didn't know it belonged to someone else" (the affirmative defense), not to deny the act.

But with insider trading and other instances of nuanced malum prohibitum [1], the usual relationship between actus reus and mens rea is inverted. To make the crime, one starts with the mens rea, the bad intent, and must identify (or, if necessary, manufacture) an apparently-normal act to register as the external offensive conduct that harmed society and warrants legal action.

That is a scarier proposition because if your daily business involves technical acts that can be converted into actus reus, there's obviously going to be ample opportunity for people to assign and rationalize their preferred ideas about your thought process there and convince themselves that you're a criminal based on their personal level of dislike or offense. If this gets brought in court, your defense will amount to convincing the jury to believe you instead of the prosecutor, which is a straight-up likability and performance contest.

Whereas, with better-defined crimes, there is a physical, independent actus reus that people recognize as objectively bad and probably intentional. If you didn't steal the thing, if they can't show that you stole the thing, that's now the ground that you're fighting over, and that's much better for the defendant because it's much less fickle.

Essentially it makes every defense necessarily affirmative because the conduct is not otherwise unlawful. The government must dislike you enough to assume bad faith first.

[0] https://en.wikipedia.org/wiki/Model_Penal_Code#Mens_rea_or_c... [1] https://www.law.cornell.edu/wex/malum_prohibitum