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

Intel SA-00145: Lazy FP State Restore

intel.com

Post reply on HN
Print view View original

111–120 of 127 posts

Re: Intel SA-00145: Lazy FP State Restore

#111

Post by Symmetry »

kinghajj wrote: post #39
jcranmer wrote: post #37

Earlier quoted context omitted.

As someone who works in compilers: no, it's not possible to make the compiler do a better job. There's a reason why VLIW architectures keep getting proposed and keep dying. The instruction-level parallelism that a CPU can extract is primarily a dynamic kind of parallelism. You can, say, have a branch that's true 1000 times, then false 1000 times, then true 1000 times, then false 1000 times, etc.--as a compiler, telli…

What are your thoughts on the Mill CPU team's claims re: their ISA allowing compilers feasibly to schedule operations statically?

They execute everything in order on a fairly short pipeline but they engage in speculative execution just like everyone else. Here's their talk on their branch predictor.

https://millcomputing.com/docs/prediction/

There's a lot less mischief you can get up to when you only execute a couple of instructions beyond a mispredicted branch rather than a hundred but mischief can't be theoretically ruled out entirely.

Re: Intel SA-00145: Lazy FP State Restore

#112

Post by Symmetry »

Tuna-Fish wrote: post #101
vbezhenar wrote: post #24

Earlier quoted context omitted.

I wonder why do we have to rely on CPU to parallelize code. Surely compiler could do better job and CPU should just offer transistors without any smart logic. It's not backwards-compatible and I'm aware about Itanium fiasco, but I'm not compelled that it's a wrong way.

The compiler cannot compete with the CPU because the CPU has strictly more information. Any memory access can take between 4 and thousands of cycles of time to execute, and the compiler won't know how long any of them take. The CPU can reorder based on exact knowledge.

Using profile guided optimization can help a lot with this in practice, though it isn't perfect.

Re: Intel SA-00145: Lazy FP State Restore

#113

Post by tomerv »

rurban wrote: post #84
ajross wrote: post #68

Earlier quoted context omitted.

All CPUs speculate to some extent (branch prediction has been on everything for basically 30 years now). Intel CPUs got hit first because they're the first ones to speculate so deeply that you can discriminate cache behavior like this. The caches and pipelines just aren't big enough elsewhere, but the techniques are all the same.

Nope, Intel got hit because they did it wrong, and the others did it right. If you speculate you need two status registers. One for the good and one for the bad case. Same for meltdown: you need one for the kernel and one for user space. Intel didn't care, others do. But Intel got the government ("legal") backdoors in. Priorities.

What are you talking about?

Re: Intel SA-00145: Lazy FP State Restore

#114

Post by olliej »

Animats wrote: post #89
olliej wrote: post #43

Earlier quoted context omitted.

Thought it was effected by spectre - meltdown was the exploit that only effected a subset of the market. Meltdown is specifically due to load speculation happening prior to verifying access permissions. Spectre is more generally due to load speculation modifying the cache while inside a branch speculation context. Basically it effected every high performance cpu in some way. Note that saying there’s a protected/safe…

In this context, getting "affect" and "effect" straight is important.

details :)

Re: Intel SA-00145: Lazy FP State Restore

#115

Post by kjeetgill »

burb_xry wrote: post #100
4ad wrote: post #96

Earlier quoted context omitted.

> I'm honestly surprised that Red Hat can't manage to keep their distros current with stable package builds. This is very wrong. It would be trivial for Red Hat to update the kernel shipped into RHEL. It's not a question that they "can't keep up". What they are doing is much more difficult and takes much more effort. They are backporting all security fixes, and sometimes other features from newer kernels to older ker…

The problem with that is that I'd argue it is "safer" to run a kernel.org stable kernel rather than RHEL, since it's sheer impossible to keep up with the amount of fixes that eventually land in stable kernels every few weeks. And it is unclear which of the stable fixes are security relevant ones even if they did not get a CVE number and the like. QAing all these is another mammoth task that often requires expertise i…

That's not the choice customers have. The parent gave examples for why companies often need predictability and stable ABIs. They're choosing between no kernel upgrades and RHEL's.

What good is a fresh kernel if a binary driver you need but can't change breaks?

Re: Intel SA-00145: Lazy FP State Restore

#116

Post by Tuna-Fish »

tomerv wrote: post #113
rurban wrote: post #84

Earlier quoted context omitted.

Nope, Intel got hit because they did it wrong, and the others did it right. If you speculate you need two status registers. One for the good and one for the bad case. Same for meltdown: you need one for the kernel and one for user space. Intel didn't care, others do. But Intel got the government ("legal") backdoors in. Priorities.

What are you talking about?

Meltdown was caused by Intel not checking privileges correctly in a speculated context, choosing to defer such checks as long as possible. This allowed the worst and easiest to use exploit, making it possible to read from any mapped location in memory. Most other CPUs did things right even in speculated contexts.

(Intel wasn't quite alone in this, though -- at least one ARM core also had this issue.)

Re: Intel SA-00145: Lazy FP State Restore

#117

Post by kbenson »

kevin_thibedeau wrote: post #107
makomk wrote: post #93

Earlier quoted context omitted.

Yeah, as of a few years ago Red Hat only give access to the proper broken-out set of patches they include in their kernel to paying customers, and they make those customers sign a contract agreeing not to distribute those patches. (They're also the only major distro who doesn't cooperate with the upstream stable releases.)

How is that not a GPL violation?

The source code is released, it's just the formatting that has changed. Presumably the contract is around the extra effort RedHat puts into making the source nice and easily manageable by providing what they used to by default, a pristine kernal and a bunch of patches to apply.

The normal method now is that they provide a large, pre-patches kernel source, which is then built. In both cases, the same code source is used for building,it's just the transformations before the building which are different, so that's likely how it doesn't violate the GPL.

The GPL says the source must be shipped, but it makes no provisions for how easy it is to read. It's sort of like if you shipped a JS lib as minified to comply with the GPL, but have a separate non-minified version to develop on in-house.

In the end, it doesn't stop anyone from downloading and compiling their own RedHat kernel as CentOS does, and Oracle Linux did(does?), but it does make it harder (not impossible) for Oracle to come in to RHEL customers and say "hey, stop your RHEL contracts, and pay us instead, and we'll support your systems without you having to reinstall." which is capitalizing on RedHat's packaging and testing work.

Re: Intel SA-00145: Lazy FP State Restore

#118

Post by Taniwha »

blattimwind wrote: post #102
Taniwha wrote: post #57

Earlier quoted context omitted.

you can do this to some degree on most CPU's - moving loads away from their results being used - compilers, esp on RISC machines with lots of registers, do this today VLIW machines allow you to provide hints about instruction level parallelism without all the superscalar on-the-fly analysis of instruction level data dependencies (so the hardware can do all that rescheduling on the fly). I think that if interlock-free…

> I think that if interlock-free software scheduled CPUs allowed us to reach 20GHz clock speeds where complex superscalar machines were stuck at 3GHz we'd all be jumping ship - but they're not Additionally, realize that clock speeds are not a relevant performance metric. Maybe, perhaps, it's possible for a software scheduled CPU to run at 2*n GHz, but that's not interesting, if it's slower in real-world workloads tha…

right, that's why we don't have really high clock speeds - that's not the point here

Re: Intel SA-00145: Lazy FP State Restore

#119

Post by Taniwha »

AstralStorm wrote: post #75
Taniwha wrote: post #57

Earlier quoted context omitted.

you can do this to some degree on most CPU's - moving loads away from their results being used - compilers, esp on RISC machines with lots of registers, do this today VLIW machines allow you to provide hints about instruction level parallelism without all the superscalar on-the-fly analysis of instruction level data dependencies (so the hardware can do all that rescheduling on the fly). I think that if interlock-free…

Essentially the CPU is running a JIT branch optimization and speculative loads which cannot ever be matched by static optimization. The interesting part is that any JIT compiler that is so dynamic in performance will have these problems. The solution might be to actually prevent some kind of security important code from being optimized in this way. Say, forcing full cache sync in-order execution for parts of code wit…

hmm ... I wonder if there are JiT compilers with smallish caches that are susceptible to these attacks (but over much larger time scales)

Re: Intel SA-00145: Lazy FP State Restore

#120

Post by techntoke »

burb_xry wrote: post #100
4ad wrote: post #96

Earlier quoted context omitted.

> I'm honestly surprised that Red Hat can't manage to keep their distros current with stable package builds. This is very wrong. It would be trivial for Red Hat to update the kernel shipped into RHEL. It's not a question that they "can't keep up". What they are doing is much more difficult and takes much more effort. They are backporting all security fixes, and sometimes other features from newer kernels to older ker…

The problem with that is that I'd argue it is "safer" to run a kernel.org stable kernel rather than RHEL, since it's sheer impossible to keep up with the amount of fixes that eventually land in stable kernels every few weeks. And it is unclear which of the stable fixes are security relevant ones even if they did not get a CVE number and the like. QAing all these is another mammoth task that often requires expertise i…

Right.. it's like they haven't managed to automate a CI pipeline to handle these changes for them. Other distros do it just fine, and I've had far more things break in CentOS or Red Hat than Arch.
Post reply on HN