3 ms·

It is sad that the solution is to cripple the software. I hope that these workarounds will be relegated to compatibility issues in the future as the underlying

It is sad that the solution is to cripple the software. I hope that these workarounds will be relegated to compatibility issues in the future as the underlying hardware is eventually fixed.

supermatt 8y ago
Not sure why i got downvoted for this. Anyone care to enlighten me?
- deleted 8y ago
  [deleted]
- MiroF 8y ago
  Any solution requires "crippling the software" - process isolation increases overhead through kernel context switches
  - supermatt 8y ago
    I suppose this is where I realise I don't actually understand the underlying issue. If it is a software issue, why is there so much blame directed to the hardware vendors?
    - MiroF 8y ago
      It's a hardware issue - ie. it is caused by compromises hardware made to speed up execution times. Because we're stuck with the hardware we have, we can make software fixes - however they are going to require either slowing down or removing certain features until we get a hardware fix for the issue.
      - supermatt 8y ago
        thank you. I read in another comment that this isn't an issue with process isolation of memory (which I originally thought), its an issue with the isolation of memory within the process - would you say that is a good summarisation? i.e. the hardware is working as designed, but the software is expecting guarantees that the hardware never promised?
        MiroF 8y ago
        I think that's a matter of debate - I personally don't think hardware should allow any sort of memory leakage in an otherwise safe language. It also renders any attempt to move critical software out of the kernel and into user-space very dangerous. With meltdown, the issue was definitely a failure of the hardware vendors obligation -> Kernel memory should definitely not be exposed to the process and yet it was. I would say such a justification is somewhat of a cop-out by the hardware vendors.
        int_19h 8y ago
        Spectre only allows access to the process' own address space, yes. But Meltdown works across processes, so hardware manufacturers (and specifically Intel) have definitely dropped the ball there, as well.
        gpderetta 8y ago
        But meltdown is known to be fixable without significant performance costs (proof being the existing high performance CPUs that are immune to it). Spectre not so much.
        MiroF 8y ago
        The problem is the same. The fact that we can hide most of the kernel memory is handy, but it shouldn't be up to the software to do that - user processes shouldn't be able to access memory that pagefaults. Definitely a dropped ball by the manufacturer
        gpderetta 8y ago
        Not the same. As you say, a process should not be able to access pages that are protected by hardware permission bits. That's exactly the issue with meltdown. Spectre is different, it allows reading pages that a process would already have hardware permission to read[1] but actual permission is enforced at the software level (i.e. software as opposed to hardware bound checking). [1] It is possible to construct spectre v1 attacks against other processes in some cases, but are much harder, low bandwidth and I do not think are yet shown to be practical.
kllrnohj 8y ago
No software was crippled here. Process isolation is arguably the way it should have always been in the first place. Hell, rebrand it as "hardware accelerated sandboxing" and now it's an obviously superior approach, right? ;) But either way nothing was actually "crippled", and if anything the reverse is true. They are un-crippling aspects of JavaScript (like re-introducing SharedArrayBuffer).

It is sad that the solution is to cripple the software. I hope that these workarounds will be relegated to compatibility issues in the future as the underlying hardware is eventually fixed.

supermatt 8y ago

Not sure why i got downvoted for this. Anyone care to enlighten me?

deleted 8y ago
[deleted]
MiroF 8y ago
Any solution requires "crippling the software" - process isolation increases overhead through kernel context switches
- supermatt 8y ago
  I suppose this is where I realise I don't actually understand the underlying issue. If it is a software issue, why is there so much blame directed to the hardware vendors?
  - MiroF 8y ago
    It's a hardware issue - ie. it is caused by compromises hardware made to speed up execution times. Because we're stuck with the hardware we have, we can make software fixes - however they are going to require either slowing down or removing certain features until we get a hardware fix for the issue.
    - supermatt 8y ago
      thank you. I read in another comment that this isn't an issue with process isolation of memory (which I originally thought), its an issue with the isolation of memory within the process - would you say that is a good summarisation? i.e. the hardware is working as designed, but the software is expecting guarantees that the hardware never promised?
      - MiroF 8y ago
        I think that's a matter of debate - I personally don't think hardware should allow any sort of memory leakage in an otherwise safe language. It also renders any attempt to move critical software out of the kernel and into user-space very dangerous. With meltdown, the issue was definitely a failure of the hardware vendors obligation -> Kernel memory should definitely not be exposed to the process and yet it was. I would say such a justification is somewhat of a cop-out by the hardware vendors.
      - int_19h 8y ago
        Spectre only allows access to the process' own address space, yes. But Meltdown works across processes, so hardware manufacturers (and specifically Intel) have definitely dropped the ball there, as well.
        gpderetta 8y ago
        But meltdown is known to be fixable without significant performance costs (proof being the existing high performance CPUs that are immune to it). Spectre not so much.
        MiroF 8y ago
        The problem is the same. The fact that we can hide most of the kernel memory is handy, but it shouldn't be up to the software to do that - user processes shouldn't be able to access memory that pagefaults. Definitely a dropped ball by the manufacturer
        gpderetta 8y ago
        Not the same. As you say, a process should not be able to access pages that are protected by hardware permission bits. That's exactly the issue with meltdown. Spectre is different, it allows reading pages that a process would already have hardware permission to read[1] but actual permission is enforced at the software level (i.e. software as opposed to hardware bound checking). [1] It is possible to construct spectre v1 attacks against other processes in some cases, but are much harder, low bandwidth and I do not think are yet shown to be practical.

kllrnohj 8y ago

No software was crippled here. Process isolation is arguably the way it should have always been in the first place. Hell, rebrand it as "hardware accelerated sandboxing" and now it's an obviously superior approach, right? ;) But either way nothing was actually "crippled", and if anything the reverse is true. They are un-crippling aspects of JavaScript (like re-introducing SharedArrayBuffer).