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

Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

bloomberg.com

Post reply on HN
Print view View original

461–470 of 567 posts

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

#461

Post by partiallypro »

chx wrote: post #98
dzink wrote: post #20

Didn’t the Intel CEO just sell half of his shares/options? If he knew about these issues isn’t that illegal?

You can be sure there's a young hotshot with sparkling eyes at SEC who is already typing a letter to Mr. Krzanich politely asking about the circumstances of that sell. At the same time, noone is doing eight figures transactions which require reporting to the SEC without talking to a lawyer. Right? Right? They really dislike insider trading, it's one of the few things where even rich people can get imprisoned -- and t…

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.

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

#462

Post by rincebrain »

rincebrain wrote: post #186
userbinator wrote: post #147

Earlier quoted context omitted.

If you overflow that buffer, you can overwrite the return address in the kernel stack, which you can then launch into ROP. The crucial point here being that there must already be an existing overflow vulnerability in the kernel. Knowing all the addresses is no use if you can't force execution to go to them.

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 into the umbrella soon

- macOS implemented partial mitigations in 10.13.2 and apparently has some novel ones coming up in 10.13.3 [2]

- someone reasonably respected claims to have a private PoC of this bug leaking kernel memory [3]

- ARM64 has KPTI patches that aren't in Linus's tree yet [4] [6] ([6] is just a link showing the patches from 4 aren't in Linus's tree as of this writing)

- all the other free operating systems appear to have been left out of the embargoed party (until recently, in FBSD's case), so who knows when they'll have mitigations ready [5]

- So far, Microsoft appears to have only patched Windows 10, so it's unknown whether they intend to backport fixes to 7 or possibly attempt to use this as another crowbar to get people off of XP 2.0

- Update: Microsoft is pushing an OOB update later today that will auto-apply to Win10 but not be forced to auto-apply on 7 and 8 until Tuesday, so that's nice [7]

[1] - https://newsroom.intel.com/news/intel-responds-to-security-r...

[2] - https://twitter.com/aionescu/status/948609809540046849

[3] - https://twitter.com/brainsmoke/status/948561799875502080

[4] - https://patchwork.kernel.org/patch/10095827/

[5] - https://lists.freebsd.org/pipermail/freebsd-security/2018-Ja...

[6] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[7] - https://www.theverge.com/2018/1/3/16846784/microsoft-process...

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

#463

Post by rbanffy »

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.

If your workload has no code that's untrusted, you can safely skip this patch or disable it on boot. If not, at 2000+ physical machines, it may be worth to move some of that into kernel modules that would collapse a couple syscalls into a single higher level one.

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

#464

Post by qubex »

exabrial wrote: post #315
qubex wrote: post #292

I’m not (yet) clear on if/how this impacts aarch64 (ARM architecture) chips, the distinction between how it affects Intel vs. doesn’t affect AMD reminds us of a fundamental lesson we seem to have conveniently forgotten: monocultures of anything are bad. We need diversity and diversification in order to have reasonable amount of robustness in the face of unknowable, unpredictable risks. I’m wondering whether ARM chips…

Yep, I'm still wondering how this affects ARM and if it can be corrected in microcode on that platform. I'm also wondering if/hoping for a fix that involves increased memory usage instead of the speed.

I’m not a very proficient programmer/developer, so please bear with me. I’m intrigued by your reference to trading off greater memory footprint in exchange for diminishing performance by less. I'm trying to understand how this would work in practice: do you envision ‘padding’ the critical data structures with more empty or randomised buffer zones? Wouldn't that incur an additional penalty for the data transfer (Von Neumann bottleneck)? Would blank data be sufficient or would there be some additional kind of memory effect in the DRAM/SRAM that would demand using randomised data overwrites? How would you generate that random data?

(I apologise if this is blindingly obvious for somebody well versed in low-level programming.)

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

#465

Post by anarazel »

eropple wrote: post #291
mtanski wrote: post #272

Earlier quoted context omitted.

We're still learning, but it looks like pgbench is 7% to 15% off: https://www.postgresql.org/message-id/20180102222354.qikjmf7...

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.

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

#466

Post by anarazel »

chillydawg wrote: post #176
jcriddle4 wrote: post #135

Earlier quoted context omitted.

I would love to see some SQL Server benchmarks on this patch

Likely very similar to the postgres benchmarks. Fundamentally a RDBMS needs to sync each transaction commit to the log file on disk and that sync is always a syscall. If your DB is doing thousands tx/sec to low latency flash and you rely on that low latency, you're going to get hit.

Note that the postgres benchmark numbers passed around (most based on my benchmarks) are readonly. For write based workloads the overhead is likely going to be much smaller in nearly all cases, there's just more independent workload. The overhead in the readonly load profiles comes near entirely from the synchronous clientserver communication, if you can avoid that for workloads (using pipelining, other batching techniques) the overhead's going to be smaller.

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

#467

Post by throwaway613834 »

Pharaoh2 wrote: post #416
throwaway613834 wrote: post #258

Earlier quoted context omitted.

> If you can read kernel (and hypervisor) memory then it seems like a very small step from that to a local root vulnerability - e.g. forge some kind of security token by copying it. This seems very wrong. I'm not aware of any privilege isolation in Windows relying on the secrecy of any value. Security tokens have opaque handles for which "guessing" makes no sense. Are you aware of anything?

I can think of a few ways to get privilege escalation if you already have rce as unprivileged user: 1. Read the root ssh private key from the openssh deamons kernel pages maintaining the crypto context and ssh into the system 2. Read a sudo auth key generated for someone using sudo and then use that to run code as a root user 3. Read the users password's whenever a session manager asks the users to reauth 4. If runni…

Thanks! I see. So it seems like the program basically has to capture sensitive data while it is in I/O transfer (and hence in kernel memory) just at the right time, right? Which is annoying and might need a bit of luck, but still possible.

Incidentally, this seems to indicate that zero-copy I/O is actually a security improvement as well, not just a performance improvement?

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

#468

Post by chx »

partiallypro wrote: post #461
chx wrote: post #98

Earlier quoted context omitted.

You can be sure there's a young hotshot with sparkling eyes at SEC who is already typing a letter to Mr. Krzanich politely asking about the circumstances of that sell. At the same time, noone is doing eight figures transactions which require reporting to the SEC without talking to a lawyer. Right? Right? They really dislike insider trading, it's one of the few things where even rich people can get imprisoned -- and t…

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.

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

#469

Post by pkaye »

rbanffy wrote: post #427
exabrial wrote: post #317

Earlier quoted context omitted.

There's also latency though :/ it seems that programs that make a lot of syscalls will be affected more than programs that are doing in-process calculations

We'll start being more syscall conscious when we write our programs. We'll batch more at the user mode side and try to use less syscalls to do the job. Kernel ABIs will eventually reflect that and crop up higher level expensive calls that replace groups of currently cheap syscalls (that will become expensive after the fix). And Intel will profit handsomely from next generation CPUs that'll get an instant up-to-30% pe…

What about all the kernel interrupts due to network and storage traffic?

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

#470

Post by Dylan16807 »

zzzcpan wrote: post #225
gagabity wrote: post #214

Is there any real danger for desktop users? We should be allowed to skip this patch if we dont want it, I would rather take the risk than the performance hit.

For desktop users there should not be any noticeable performance degradation. But they are also likely the ones in the most danger, since they execute random code in their web browsers.

Random code that makes direct kernel calls? Or is that not necessary?
Post reply on HN