31–40 of 298 posts
All Intel CPU's are affected, mitigation syscall overhead increased by 50%, and none of AMD CPU's affected? I would say this could be an indicator to short INTC and long AMD...
Short INTC maybe but I am not sure this means that AMD will increase in value over the long run as a result of this one incident.
Earlier quoted context omitted.
I'm curious what you are referring to re: the DLC concept? Did you mean this thing? https://en.wikipedia.org/wiki/Intel_Upgrade_Service Seems like that was discontinued a long time ago (2011) so was wondering if there was something more recent that happened?
Probably the paid hardware RAID unlock key.
Earlier quoted context omitted.
Short INTC maybe but I am not sure this means that AMD will increase in value over the long run as a result of this one incident.
What about this combined with the Intel ME stuff? I could see large cloud providers starting to at least think about switching to AMD
Earlier quoted context omitted.
I'm curious what you are referring to re: the DLC concept? Did you mean this thing? https://en.wikipedia.org/wiki/Intel_Upgrade_Service Seems like that was discontinued a long time ago (2011) so was wondering if there was something more recent that happened?
Probably the paid hardware RAID unlock key.
Earlier quoted context omitted.
Interesting. I can see it being a concern in shared environments (hence all the cloud providers are quite scared), but unless there's another part about being able to modify kernel memory, IMHO it's not such a big deal for the typical single-user personal computer. I wonder if there are other (non-x86) CPUs that do similar speculative execution affected... the general ideas behind it don't seem to be specific to x86.
> IMHO it's not such a big deal for the typical single-user personal computer IDK. If this means that some JavaScript from a website can read my kernel's memory, then it seems like a big deal.
...but the blog post above shows that you need to execute instructions that (try to) access kernel addresses, and have a handler in place to catch the inevitable exception. That doesn't seem like code a JS JIT could generate.
You might be thinking of that JS RowHammer demonstration, but that was using regular memory accesses and not with the specific kernel addresses that you need for this.
A major underlying cause is that we're doing things in hardware that ought to be done in software. We really need to stop shipping software as native blobs and start shipping it as pseudocode, allowing the OS to manage native execution. This would allow the kernel and OS to do tons and tons of stuff the CPU currently does: process isolation, virtualization, much or perhaps even all address remapping, handling virtual memory, etc. CPUs could just present a flat 64-bit address space and run code in it.
These chips would be faster, simpler, cheaper, and more power efficient. It would also make CPU architectures easier to change. Going from x64 to ARM or RISC-V would be a matter of porting the kernel and core OS only.
Unfortunately nobody's ever really gone there. The major problem with Java and .NET is that they try to do way too much at once and solve too many problems in one layer. They're also too far abstracted from the hardware, imposing an "impedance mismatch" performance penalty. (Though this penalty is minimal for most apps.)
What we need is a binary format with a thin (not overly abstracted) pseudocode that closely models the processor. OSes could lazily compile these binaries and cache them, eliminating JIT program launch overhead except on first launch or code change. If the pseudocode contained rich vectorization instructions, etc., then there would not be much if any performance cost. In fact performance might be better since the lazy AOT compiler could apply CPU model specific optimizations and always use the latest CPU features for all programs.
Instead we've bloated the processor to keep supporting 1970s operating systems and program delivery paradigms.
It's such an obvious thing I'm really surprised nobody's done it. Maybe there's a perverse hardware platform lock-in incentive at work.
Earlier quoted context omitted.
> IMHO it's not such a big deal for the typical single-user personal computer IDK. If this means that some JavaScript from a website can read my kernel's memory, then it seems like a big deal.
All the more reason to keep JS off by default... ...but the blog post above shows that you need to execute instructions that (try to) access kernel addresses, and have a handler in place to catch the inevitable exception. That doesn't seem like code a JS JIT could generate. You might be thinking of that JS RowHammer demonstration, but that was using regular memory accesses and not with the specific kernel addresses t…
Is there enough spare capacity to cope with this? Will spot-instance prices go up? Will I need more instances of a given type to run the same workload?
Earlier quoted context omitted.
The text as written only seeks to defend AMD's product. Whether the sub text goes further is open to non objective speculation. Having said that I'm sure AMD are feeling pretty happy with their statement. Schadenfreude may be too long a bow...
What are you talking about? Every other single CPU vendor with an MMD, arm, s390, Sparc, ... either has a separate page translation table register for kernel and user space, or like AMD memory page capabilities, just Intel not. It's very clear who is at fault here.
All Intel CPU's are affected, mitigation syscall overhead increased by 50%, and none of AMD CPU's affected? I would say this could be an indicator to short INTC and long AMD...