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

101–110 of 127 posts

Re: Intel SA-00145: Lazy FP State Restore

#101

Post by Tuna-Fish »

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

Earlier quoted context omitted.

Completely dropping all forms of speculative execution means dropping overall performance to a tenth of today. There are really hard limits on how fast any operation, especially memory operations, can be done. The way we have made our CPUs faster is by making them do more operations in parallel, at all levels. At the lowest level, in straight line code, this very often requires speculation to achieve. Speculation is…

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.

Re: Intel SA-00145: Lazy FP State Restore

#102

Post by blattimwind »

Taniwha wrote: post #57
kinghajj wrote: post #39

Earlier quoted context omitted.

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

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 than todays tech at n GHz. And for breadth-deployment in data centers we're mostly looking at throughput per Watt. CPUs with high clock speeds don't do well in that area because semiconductor physics.

Re: Intel SA-00145: Lazy FP State Restore

#103

Post by xnyanta »

vbezhenar wrote: post #26
snuxoll wrote: post #20

Earlier quoted context omitted.

Red Hat backports security fixes, hardware support and certain new features to their kernel packages, staying on a stable kernel version throughout the product lifecycle is what allows them to guarantee a consistent kernel ABI that virtually every other distribution throws to the wayside. Personally I prefer not having third-party kernel modules on my servers break every time I run `yum upgrade` like I do with Fedora…

I'm using HP B120i fakeraid controller with proprietary driver and it broke after 7.4 upgrade, so while they probably doing a good job about binary compatibility (7.5 didn't broke it), it's not ideal.

I really hate HP for this stupid fakeraid shit. The regular SATA AHCI controller is unusable on the HP servers I have because it does not pass the temperature info to the iLO and causes the fans to skyrocket to 70% permanently.

Obviously, using the B120i was out of question due to their crappy driver only targeting RedHat's ancient kernel so my only viable solution was to have to go out and purchase a 200$ real HP P420 smart array RAID card to connect my drives to.

Re: Intel SA-00145: Lazy FP State Restore

#104

Post by Symmetry »

ajross wrote: post #70
dnautics wrote: post #59

Earlier quoted context omitted.

There are architectural choices for pipelined systems you can make that don't specex, but it requires compiler level optimization to take advantage of them, so it's a chicken and egg problem to get adoption

Been there, done that, didn't work. VLIW has been tried a dozen times and failed every time.

I think you're being too dismissive here. First of all, VLIW has been hugely successful in DSP cores. Your phone probably has a few in it. Second, Itanium wasn't great but it wasn't terrible either. And the Transmeta/NVidia lineage have also been not terrible. There isn't any reason to choose them over a conventional OoO processor absent security concerns but if they really do help with security concerns then these approaches bear careful investigation.

Re: Intel SA-00145: Lazy FP State Restore

#105

Post by Symmetry »

makomk wrote: post #94
eridius wrote: post #79

Earlier quoted context omitted.

If the attacker can do timing on their side in a pure function, then by definition the time the response takes is one of the function inputs.

Haskell functions are only pure in an abstract sense that ignores micro-architectural side-effects and the resulting timing changes. All of the recent speculative side-channel attacks are the result of the abstraction layer exposed by modern processors leaking. You can't fix this by putting more abstraction layers with neat theoretical properties on top.

You can't be guaranteed to prevent the attacker form writing information to those side channels but you can guarantee that the attacker can't read from those side channels because reading from them requires doing timing analysis and timing analysis requires IO - which we've stipulated hasn't been passed to the attacking function.

Re: Intel SA-00145: Lazy FP State Restore

#106

Post by mwcampbell »

kentonv wrote: post #30
Tuna-Fish wrote: post #18

Earlier quoted context omitted.

Completely dropping all forms of speculative execution means dropping overall performance to a tenth of today. There are really hard limits on how fast any operation, especially memory operations, can be done. The way we have made our CPUs faster is by making them do more operations in parallel, at all levels. At the lowest level, in straight line code, this very often requires speculation to achieve. Speculation is…

> Going forward, the only reasonable assumption is that if you let a third party run their code in a process, no matter how you verify accesses or otherwise try to contain that code, you should assume it has a read access to the entire process. If this is true, it is unbelievably bad for the future of security and computing in general. People throwing around this assertion are, in my opinion, not appreciating how bad…

On JavaScript being a secure sub-process sandbox, as my manager told me months before Spectre, "Pwn2Own says otherwise." Much to my disappointment.

Re: Intel SA-00145: Lazy FP State Restore

#107

Post by kevin_thibedeau »

makomk wrote: post #93
kbenson wrote: post #67

Earlier quoted context omitted.

The nice thing is that it's all fully documented. If you download the kernel src.rpm[1] and install it, you'll get the kernel RPM spec file in your default RPM build environment paths (or use rpm2cpio $KERNEL_SRPM | cpio -idmv). The way the RPM building works is to take a vanilla kernel and then apply a LOT of individual patch files to it, each with their own entry. Well, at least that's how it was a long time ago wh…

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?

Re: Intel SA-00145: Lazy FP State Restore

#108

Post by mokus »

tylerhou wrote: post #29
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.

A quote I once heard from a friend: "Don't turn your normal problem into a distributed systems problem."

Arguably, the reason for Spectre, etc., is that people have failed to realize that at the scale of modern intel CPUs, these problems already are distributed systems problems.

Re: Intel SA-00145: Lazy FP State Restore

#109

Post by Symmetry »

ori_b wrote: post #48
JudasGoat wrote: post #35

Earlier quoted context omitted.

I know the Arm A-53 isn't cutting edge fast, but hardly one tenth. Seeing as the A-53 is unaffected by both Meltdown and Spectre, my assumption was that it didn't use speculative execution.

It's affected by spectre, but not meltdown.

No, neither.

https://developer.arm.com/support/arm-security-updates/specu...

Re: Intel SA-00145: Lazy FP State Restore

#110

Post by Symmetry »

jcranmer wrote: post #37
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.

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…

VLIWs can make use of the same branch predictors that you see in out of order cores like an Intel Core or in order cores like an ARM A53. The big problem that VLIW faces is starting loads early so that they've finished by the time you need their contents. Itanium tried to do that but their mechanism really broke down in the face of possible memory exceptions and it didn't speed things up much. Mill has a cleverer way to speculate with loads which might work better but it's still entirely unable to speculatively load values across boundaries between codebases, like system calls. But of course speculatively loading across system calls is what's causing problems here. So it might be that the best thing is to accept the 80% performance solution in the same of security through keeping the hardware simple enough to understand.
Post reply on HN