7 ms·

Would a hardware fix also eliminate the perf degradation that the software fixes introduced? Or does it just increase security?

mlindner 9y ago
It should (depending on how they implement it), as long as the software is re-modified to run the original way on only this platform and later. The performance degradation at least would move into hardware instead of software.
- samfisher83 9y ago
  How are they going to fix it without some performance penalty. If the memory is in cache isn't there going to be a timing difference? or an extra check will have to be made which is going to have to slow down the lookup?
  - swsieber 9y ago
    From what I underst and this fixes variants two and three which are cross ring and cross process data extraction. I believe their hardware mitigation is to separate the caches between those (or something to that effect). So there will still be a minor penalty hit for running multiple identical process compared to before. That's my interpretation though, I don't know enough to say that's the correct interpretation.
    - Someone1234 9y ago
      Does the hardware on x86 even know which cache is owned by which process? It knows which is elevated (kernel Vs. User Vs. Hypervisor, etc) but process isolation on x86 is largely a kernel API construct rather than a hardware one. Unless I'm mistaken.
      - rzzzt 9y ago
        The answer is yes, if the processor supports PCID: https://news.ycombinator.com/item?id=16094349 https://news.ycombinator.com/item?id=16094349 Simplistically, it allows TLB-cached page table contents to be tagged with a context identifier, and limits the lookups in the TLB to only match within the currently allowed context. TLB cached entires with a different PCID will be ignored.
        hansendc 9y ago
        I think you are confusing the TLB and processor data caches. PCIDs exist for virtual addresses and are implemented in the TLB, not the processor caches. The processor caches are physically indexed, not virtually indexed. So, does the processor cache have a mechanism to tell which "process" to which a given line belongs? Nope. Two processes (or a process and the kernel) that share memory can be in two PCIDs, but share the processor caches.
        rzzzt 9y ago
        You are correct. My assumption was that the original question is not focused on the data cache itself, and so the DTLB does qualify for "knowing" what belongs to which context.
  - deleted 9y ago
    [deleted]
  - bitL 9y ago
    > to fix it without some performance penalty. 10nm + higher frequency?
  - PeterisP 9y ago
    An additional check can be made in the same time in parallel if there's extra hardware (specific gates) assigned to do that.
classics2 9y ago
Only in that you don’t be able to directly measure it anymore because the mitigation is buried in the performance data of a new processor.
nonbel 9y ago
From the intel press release: >"As we bring these new products to market, ensuring that they deliver the performance improvements people expect from us is critical. Our goal is to offer not only the best performance, but also the best secure performance." https://newsroom.intel.com/editorials/advancing-security-silicon-level/ https://newsroom.intel.com/editorials/advancing-security-sil...
- dredmorbius 9y ago
  That's a non-answer answer. It doesn't say there will be no degradation. Only that that might be minimised.
  - sintaxi 9y ago
    Isn't it clear? Performance is top priority and security is also top priority. edit: apparently sarcasm on the web doesn't work very well.
    - dredmorbius 9y ago
      ...and an almost fanatical devotion to the Pope, and nice red uniforms.
    - dredmorbius 9y ago
      It (sarcasm) never has, though, yes.
    - notriddle 9y ago
      And reliability is also top priority. And minimizing cost is also top priority. [/sarcasm]
    - ComputerGuru 9y ago
      It’s pretty well known that when you say you have multiple top priorities, what you really mean to say is that marketing is your top priority.
  - derefr 9y ago
aeleos 9y ago
We can't really know, since we don't have something to compare it to. Only they know what the performance could have been if the fix were not implemented in silicon, and they won't be releasing new versions of old chips that ONLY have this hardware fix, so we will never be able to compare the two. Only they will ever know, however if we see comparable or worse performance (or just barely better) in these new chips then we can know that there was some performance hit.
nhaehnle 9y ago
I'd say both Spectre 2 and Meltdown are fairly straightforward to fix in hardware without performance degradation (though probably at the cost of a bit more circuitry), so that's most likely what they did. For Meltdown, you need to just never load data from L1$ when permissions checks fail. Since address translation is already on the L1$, doing permissions checks there as well is not a big burden. This is quite natural to do, and also why Meltdown specifically affected Intel, and not everybody. For Spectre 2, you need to add some bits to the branch target buffer to tag entries by the privilege level and ideally PCID (to protect user level processes from each other). And then you just don't use BTB entries with the wrong tag. It'd still be interesting to know the details, e.g. what exactly they changed for Spectre 2.
- bzbarsky 9y ago
  Your proposal doesn't fix Spectre 2 in general; just the cross-privilege level (or at best cross-process) aspect. Anyone trying to create a sandbox still has to worry about the sandboxed stuff being able to read all of the sandbox memory, for example.
  - nhaehnle 9y ago
    That's a good point. Ideally the ISA would allow user level code to also toggle a flag that affects the BTB. That would allow embedding JIT code while guarding against Spectre 2 (fixing the BTB injection). I don't think you really need more than that though. Reading arbitrary memory would seem to require a Spectre 1-type attack instead. Unless you have an explicit counterexample in mind? For the JIT'ed code, Spectre 1 can probably be mostly avoided using the bitmask trick or something equivalent, which we seem to be moving in the direction of anyway (thinking about the WASM execution environment specifically), and for the "host" code inside the sandbox, the same kind of selective software fixes are required as in the kernel.
    - bzbarsky 9y ago
      I suspect you can get arbitrary memory read with Spectre 2 as well; just have to find the right gadgets. Which in a big program of the sort that would have a sandbox inside is somewhat likely... (I can't comment on specific counterexamples in more detail than that, even if I know of any.)
sitepodmatt 9y ago
Would this result in 32bit, x64, x64CPUpost2018 versions of software, as from my limited understanding apps (such as v8 engine) are being compiled with workarounds for such that won't be needed once fixed in hardware?

mlindner 9y ago

It should (depending on how they implement it), as long as the software is re-modified to run the original way on only this platform and later. The performance degradation at least would move into hardware instead of software.

samfisher83 9y ago
How are they going to fix it without some performance penalty. If the memory is in cache isn't there going to be a timing difference? or an extra check will have to be made which is going to have to slow down the lookup?
- swsieber 9y ago
  From what I underst and this fixes variants two and three which are cross ring and cross process data extraction. I believe their hardware mitigation is to separate the caches between those (or something to that effect). So there will still be a minor penalty hit for running multiple identical process compared to before. That's my interpretation though, I don't know enough to say that's the correct interpretation.
  - Someone1234 9y ago
    Does the hardware on x86 even know which cache is owned by which process? It knows which is elevated (kernel Vs. User Vs. Hypervisor, etc) but process isolation on x86 is largely a kernel API construct rather than a hardware one. Unless I'm mistaken.
    - rzzzt 9y ago
      The answer is yes, if the processor supports PCID: https://news.ycombinator.com/item?id=16094349 https://news.ycombinator.com/item?id=16094349 Simplistically, it allows TLB-cached page table contents to be tagged with a context identifier, and limits the lookups in the TLB to only match within the currently allowed context. TLB cached entires with a different PCID will be ignored.
      - hansendc 9y ago
        I think you are confusing the TLB and processor data caches. PCIDs exist for virtual addresses and are implemented in the TLB, not the processor caches. The processor caches are physically indexed, not virtually indexed. So, does the processor cache have a mechanism to tell which "process" to which a given line belongs? Nope. Two processes (or a process and the kernel) that share memory can be in two PCIDs, but share the processor caches.
        rzzzt 9y ago
        You are correct. My assumption was that the original question is not focused on the data cache itself, and so the DTLB does qualify for "knowing" what belongs to which context.
- deleted 9y ago
  [deleted]
- bitL 9y ago
  > to fix it without some performance penalty. 10nm + higher frequency?
- PeterisP 9y ago
  An additional check can be made in the same time in parallel if there's extra hardware (specific gates) assigned to do that.

classics2 9y ago

Only in that you don’t be able to directly measure it anymore because the mitigation is buried in the performance data of a new processor.

nonbel 9y ago

From the intel press release: >"As we bring these new products to market, ensuring that they deliver the performance improvements people expect from us is critical. Our goal is to offer not only the best performance, but also the best secure performance." https://newsroom.intel.com/editorials/advancing-security-silicon-level/ https://newsroom.intel.com/editorials/advancing-security-sil...

dredmorbius 9y ago
That's a non-answer answer. It doesn't say there will be no degradation. Only that that might be minimised.
- sintaxi 9y ago
  Isn't it clear? Performance is top priority and security is also top priority. edit: apparently sarcasm on the web doesn't work very well.
  - dredmorbius 9y ago
    ...and an almost fanatical devotion to the Pope, and nice red uniforms.
  - dredmorbius 9y ago
    It (sarcasm) never has, though, yes.
  - notriddle 9y ago
    And reliability is also top priority. And minimizing cost is also top priority. [/sarcasm]
  - ComputerGuru 9y ago
    It’s pretty well known that when you say you have multiple top priorities, what you really mean to say is that marketing is your top priority.
- derefr 9y ago

aeleos 9y ago

We can't really know, since we don't have something to compare it to. Only they know what the performance could have been if the fix were not implemented in silicon, and they won't be releasing new versions of old chips that ONLY have this hardware fix, so we will never be able to compare the two. Only they will ever know, however if we see comparable or worse performance (or just barely better) in these new chips then we can know that there was some performance hit.

nhaehnle 9y ago

I'd say both Spectre 2 and Meltdown are fairly straightforward to fix in hardware without performance degradation (though probably at the cost of a bit more circuitry), so that's most likely what they did. For Meltdown, you need to just never load data from L1$ when permissions checks fail. Since address translation is already on the L1$, doing permissions checks there as well is not a big burden. This is quite natural to do, and also why Meltdown specifically affected Intel, and not everybody. For Spectre 2, you need to add some bits to the branch target buffer to tag entries by the privilege level and ideally PCID (to protect user level processes from each other). And then you just don't use BTB entries with the wrong tag. It'd still be interesting to know the details, e.g. what exactly they changed for Spectre 2.

bzbarsky 9y ago
Your proposal doesn't fix Spectre 2 in general; just the cross-privilege level (or at best cross-process) aspect. Anyone trying to create a sandbox still has to worry about the sandboxed stuff being able to read all of the sandbox memory, for example.
- nhaehnle 9y ago
  That's a good point. Ideally the ISA would allow user level code to also toggle a flag that affects the BTB. That would allow embedding JIT code while guarding against Spectre 2 (fixing the BTB injection). I don't think you really need more than that though. Reading arbitrary memory would seem to require a Spectre 1-type attack instead. Unless you have an explicit counterexample in mind? For the JIT'ed code, Spectre 1 can probably be mostly avoided using the bitmask trick or something equivalent, which we seem to be moving in the direction of anyway (thinking about the WASM execution environment specifically), and for the "host" code inside the sandbox, the same kind of selective software fixes are required as in the kernel.
  - bzbarsky 9y ago
    I suspect you can get arbitrary memory read with Spectre 2 as well; just have to find the right gadgets. Which in a big program of the sort that would have a sandbox inside is somewhat likely... (I can't comment on specific counterexamples in more detail than that, even if I know of any.)

sitepodmatt 9y ago

Would this result in 32bit, x64, x64CPUpost2018 versions of software, as from my limited understanding apps (such as v8 engine) are being compiled with workarounds for such that won't be needed once fixed in hardware?