Personal computing discussed
Moderators: renee, Flying Fox, morphine
DrDominodog51 wrote:tl:dr: Meltdown can likely be fixed in a new stepping, but Spectre will take longer to fix.
Intel wrote:Intel has developed and is rapidly issuing updates for all types of Intel-based computer systems — including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero.
article wrote:Let’s say there is an instruction that enable loads to hit and consumed even in presence of faults, or I am wrong on the above catch, why is it happening now rather than discovered decades ago.
1. Today’s CPUs have much deeper pipelines cough Prescott cough which provides a wider window between the speculative memory access and the actual nuke/squash of those faulting accesses. Faulting instructions are not handled until the instruction is up for retirement/committal to processor architectural state. Only at retirement is the pipeline nuked. Long pipelines allow for a large window between the execution of the faulting instruction and the retirement of it allowing other speculative instructions to race ahead.
article wrote:2. Larger cache hierarchy and slower memory fabric speed relative to fast CPU only ops such as cache hit/integer ops which provides a much larger time difference in cycles between a cache hit and a cache miss/memory to enable more robust cache timing attacks. Today’s large multi-core server CPUs with elaborate mesh fabrics to connect tens or hundreds of cores exaggerates this.
article wrote:Addition of performance enhancing features for fine granularity cache control such as the x86 CLFLUSH and PREFETx give more control for cache timing attacks.
article wrote:Wider issue processors that enable parallel integer, floating, and memory ops simultaneously. One could place long floating point operations such as divide or sqrt right before the faulting instruction to keep the core busy, but still keeping the integer and memory pipelines free for the attack. Since the faulting instruction will not nuke the pipeline until retirement, it has to wait until any earlier instructions in the instruction sequence to be committed including long running floating point ops.
article wrote:Virtualization and PaaS. Many web scale companies are now running workloads cloud providers like AWS and Azure. Before cloud, Fortune 500 companies would run their own trusted applications on their own hardware. Thus, applications from different companies were physically separated, unlike today. While it is unknown if Meltdown can allow a guest OS to break into the hypervisor or host OS, what is known is that many virtualization techniques are more lightweight than full blown VT-x. For example, multiple apps in Heroku, AWS Beanstalk, or Azure Web apps along with Docker containers are running within the same VM. Companies no longer spin up a separate VM for each application. This could allow a rogue application to read kernel memory of the specific VM. Shares resources were not a thing in the 90’s when OoO execution became mainstream with the Pentium Pro/Pentium III.
article wrote:The use of the Global and User/Supervisor bits in x86 paging entries which enables the kernel memory space to be mapped into every user process (but protected from Ring3 code execution) to reduce pressure on TLBs and slow context switching to a separate kernel process. This performance optimization has been done since the 1990’s.
Glorious wrote:article wrote:Let’s say there is an instruction that enable loads to hit and consumed even in presence of faults, or I am wrong on the above catch, why is it happening now rather than discovered decades ago.
1. Today’s CPUs have much deeper pipelines cough Prescott cough which provides a wider window between the speculative memory access and the actual nuke/squash of those faulting accesses. Faulting instructions are not handled until the instruction is up for retirement/committal to processor architectural state. Only at retirement is the pipeline nuked. Long pipelines allow for a large window between the execution of the faulting instruction and the retirement of it allowing other speculative instructions to race ahead.
Um.
Prescott was designed 15 years ago, sooo, uhhhh....
Glorious wrote:article wrote:2. Larger cache hierarchy and slower memory fabric speed relative to fast CPU only ops such as cache hit/integer ops which provides a much larger time difference in cycles between a cache hit and a cache miss/memory to enable more robust cache timing attacks. Today’s large multi-core server CPUs with elaborate mesh fabrics to connect tens or hundreds of cores exaggerates this.
Uhhhh... the whitepaper (which this guys claims to have read) demonstrated this on two-core celerons. The most cores they listed in any demonstrated machine numbered but 12, and those were the cloud-provided ones: even the cheapest tier of a VPS I've had for like three (maybe four?) years is still a 6 core Ivy EP. Like, they weren't even looking for a bunch of cores, that's just what their likely newer-deployed instance (haswell/broadwell) had underneath it.
Glorious wrote:So what does this "tens to hundreds" of cores have to do with this? I mean, what?
Glorious wrote:article wrote:Addition of performance enhancing features for fine granularity cache control such as the x86 CLFLUSH and PREFETx give more control for cache timing attacks.
CLFLUSH is Williamette. Which was designed two decades ago.
PREFETx goes back to the Pentium 3 and earlier, so you're talking 2 Decades PLUS.
Glorious wrote:article wrote:Wider issue processors that enable parallel integer, floating, and memory ops simultaneously. One could place long floating point operations such as divide or sqrt right before the faulting instruction to keep the core busy, but still keeping the integer and memory pipelines free for the attack. Since the faulting instruction will not nuke the pipeline until retirement, it has to wait until any earlier instructions in the instruction sequence to be committed including long running floating point ops.
I don't think there has been a serious improvement in multi-issue since the core 2.
Glorious wrote:article wrote:Virtualization and PaaS. Many web scale companies are now running workloads cloud providers like AWS and Azure. Before cloud, Fortune 500 companies would run their own trusted applications on their own hardware. Thus, applications from different companies were physically separated, unlike today. While it is unknown if Meltdown can allow a guest OS to break into the hypervisor or host OS, what is known is that many virtualization techniques are more lightweight than full blown VT-x. For example, multiple apps in Heroku, AWS Beanstalk, or Azure Web apps along with Docker containers are running within the same VM. Companies no longer spin up a separate VM for each application. This could allow a rogue application to read kernel memory of the specific VM. Shares resources were not a thing in the 90’s when OoO execution became mainstream with the Pentium Pro/Pentium III.
Uh, no one says that meltdown allows someone to break into the hyperviser/host. It's read-only. That might indirectly lead you into information you could use to do things, but uhh...
Glorious wrote:I mean, this guy claims to have read the paper, and he's just ...wrong before we get back to how they have way more "lab" demonstrators than "cloud"...
Glorious wrote:article wrote:The use of the Global and User/Supervisor bits in x86 paging entries which enables the kernel memory space to be mapped into every user process (but protected from Ring3 code execution) to reduce pressure on TLBs and slow context switching to a separate kernel process. This performance optimization has been done since the 1990’s.
In other words, since we've, you know, HAD protected virtual memory and so forth.
Glorious wrote:I mean, the whole piece is rife with self-contradiction and misrepresentation....
Redocbew wrote:I'm still a bit surprised that such a complicated timing attack is possible within an interpreted language like javascript. I would have thought that was the domain of low level C code, or something similar, and that trying to write the same thing in a higher level language would be infeasible because of all the extra stuff inbetween the code its self and the hardware, but apparently that's not the case.
JBI wrote:I think you're being a little harsh there. You're interpreting things in the worst possible way.
article wrote:Is the attack believable?
article wrote:One thing is for certain, caching and speculation are not going away anytime soon. If it is a logic bug, it may be a simple fix for future Intel CPUs.
article wrote:This isn’t an Intel specific problem or a x86 problem but rather a fundamental problem in general CPU architecture