5 ms·

Why do comments like this get rated down so quickly. The process boundary was supposed to be the level of protection. Preventing your own process from accessin

Why do comments like this get rated down so quickly. The process boundary was supposed to be the level of protection. Preventing your own process from accessing itself was never part of the memory model.

monocasa 8y ago
Chip manufacturers have known about JavaScript and it's implementations for decades. ARM for instance had gone so far as to make JS specific instructions (FJCVTZS, Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero), and before that they had instructions to help a JIT (ThumbEE). Not sure why we're buying the chip companies' shtick of "oh, poor us, we never knew people would use our chips like that, we just specifically optimized for it and provided support instructions"
- rayiner 8y ago
  So chip makers should have redesigned their hardware to match the erroneous assumptions JS vendors were making about how memory protection works?
  - monocasa 8y ago
    They should have provided mechanisms for multiple memory domains in the same process, so that people can use their chips securely to do the work the expect to do with them, yes.
    - rayiner 8y ago
      Got it. Chip makers have an obligation to accommodate (proactively, no less) stupid things developers do, like running untrusted code in the same process. Makes total sense.
      - earenndil 8y ago
        Not stupid things developers do. Chip makers should accommodate the behaviour of most users of their chips, which does include running javascript.
      - monocasa 8y ago
        They knew since the 90s that people were doing this and expecting it to work, or did you miss that whole Java thing? Java became big as Intel was adding OoOE to their cores. Hardware and software is codesigned, and yes the onus is on the chip manufacturers to release chips that let you continue to use them securely.
        tedunangst 8y ago
        Why don't software developers have the responsibility to write software that uses the existing hardware protection mechanism?
        monocasa 8y ago
        Because chip manufacturers changed their hardware after the fact and kept their changes proprietary.
      - pcwalton 8y ago
        You're trying to casually brush away the entire field of software fault isolation as "stupid things developers do". In fact, SFI has been a respectable area of systems research since at least 1987.
        rayiner 8y ago
        I'm not trying to casually brush away the whole field. MMU-based protection has been overly limiting ever since MMUs were developed. That doesn't mean that every design for providing isolation beyond what the MMU can guarantee is well-thought-out. Certainly, I see no basis for blaming chip makers for the fact that VM developers came up with an attempt at same-process isolation that doesn't work. It's like all the whining people do about GCC doing unexpected things when faced with code that relies on undefined behavior. That's not GCC's fault.
  - int_19h 8y ago
    If they were erroneous, why weren't they corrected for two decades by those very same chip makers? It was various security researchers that first warned about something like this, not an Intel engineer saying "y'all are holding it wrong".
- kllrnohj 8y ago
  > Not sure why we're buying the chip companies' shtick of "oh, poor us, we never knew people would use our chips like that, we just specifically optimized for it and provided support instructions" Hardware moves slowly and can't be fixed easily. Browsers should just be doing this (which they are with site isolation) instead of hardware trying to hack in patches to cover up bad software architecture. And you can't fix a bug you didn't know about anyway, so why would you have expected ARM to fix something nobody knew was real in the first place?
  - monocasa 8y ago
    Running untrusted code in the same process isn't "bad software architecture". And we've been doing that for as long as microprocessors have had OoOE. Java got big right when the first consumer OoOE chips came out in the 90s.
    - kllrnohj 8y ago
      > And we've been doing that for as long as microprocessors have had OoOE Prior to web browsers when was such a thing ever widespread? And if you eliminate web browsers from the picture, how many usages are even left? > Java got big right when the first consumer OoOE chips came out in the 90s. Java doesn't do this, so how is that relevant?
      - monocasa 8y ago
        > Prior to web browsers when was such a thing ever widespread? And if you eliminate web browsers from the picture, how many usages are even left? BPF has existed since the mid 90s for one example. > Java doesn't do this, so how is that relevant? Java and the client web were next to inseparable concepts at the time. Java ran their VM as a shared library in the browser process for applets.
    - stubish 8y ago
      The JVM took responsibility for sandbox isolation. It took until Spectre/Meltdown to widely demonstrate that this was a poor decision, because it turned out in process sandbox isolation is a promise that cannot be kept. And the point of the JVM was to run the same code on all sorts of hardware, so it doesn't get to blame the Intel or Spark or Motorola CPU it happens to be running on.
MiroF 8y ago
Meltdown let processes access kernel memory which was supposed to be hardware protected. That is a violation of the chipmakers obligation, not the software obligation.
- tntn 8y ago
  ... yeah. And that is a different discussion. The article, and the discussion here, is regarding side channels attacks within a single process. I'm pretty sure everyone agrees that the hardware (or some conspiracy of the hardware and kernel) must provide process isolation.

monocasa 8y ago

Chip manufacturers have known about JavaScript and it's implementations for decades. ARM for instance had gone so far as to make JS specific instructions (FJCVTZS, Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero), and before that they had instructions to help a JIT (ThumbEE). Not sure why we're buying the chip companies' shtick of "oh, poor us, we never knew people would use our chips like that, we just specifically optimized for it and provided support instructions"

rayiner 8y ago
So chip makers should have redesigned their hardware to match the erroneous assumptions JS vendors were making about how memory protection works?
- monocasa 8y ago
  They should have provided mechanisms for multiple memory domains in the same process, so that people can use their chips securely to do the work the expect to do with them, yes.
  - rayiner 8y ago
    Got it. Chip makers have an obligation to accommodate (proactively, no less) stupid things developers do, like running untrusted code in the same process. Makes total sense.
    - earenndil 8y ago
      Not stupid things developers do. Chip makers should accommodate the behaviour of most users of their chips, which does include running javascript.
    - monocasa 8y ago
      They knew since the 90s that people were doing this and expecting it to work, or did you miss that whole Java thing? Java became big as Intel was adding OoOE to their cores. Hardware and software is codesigned, and yes the onus is on the chip manufacturers to release chips that let you continue to use them securely.
      - tedunangst 8y ago
        Why don't software developers have the responsibility to write software that uses the existing hardware protection mechanism?
        monocasa 8y ago
        Because chip manufacturers changed their hardware after the fact and kept their changes proprietary.
    - pcwalton 8y ago
      You're trying to casually brush away the entire field of software fault isolation as "stupid things developers do". In fact, SFI has been a respectable area of systems research since at least 1987.
      - rayiner 8y ago
        I'm not trying to casually brush away the whole field. MMU-based protection has been overly limiting ever since MMUs were developed. That doesn't mean that every design for providing isolation beyond what the MMU can guarantee is well-thought-out. Certainly, I see no basis for blaming chip makers for the fact that VM developers came up with an attempt at same-process isolation that doesn't work. It's like all the whining people do about GCC doing unexpected things when faced with code that relies on undefined behavior. That's not GCC's fault.
- int_19h 8y ago
  If they were erroneous, why weren't they corrected for two decades by those very same chip makers? It was various security researchers that first warned about something like this, not an Intel engineer saying "y'all are holding it wrong".
kllrnohj 8y ago
> Not sure why we're buying the chip companies' shtick of "oh, poor us, we never knew people would use our chips like that, we just specifically optimized for it and provided support instructions" Hardware moves slowly and can't be fixed easily. Browsers should just be doing this (which they are with site isolation) instead of hardware trying to hack in patches to cover up bad software architecture. And you can't fix a bug you didn't know about anyway, so why would you have expected ARM to fix something nobody knew was real in the first place?
- monocasa 8y ago
  Running untrusted code in the same process isn't "bad software architecture". And we've been doing that for as long as microprocessors have had OoOE. Java got big right when the first consumer OoOE chips came out in the 90s.
  - kllrnohj 8y ago
    > And we've been doing that for as long as microprocessors have had OoOE Prior to web browsers when was such a thing ever widespread? And if you eliminate web browsers from the picture, how many usages are even left? > Java got big right when the first consumer OoOE chips came out in the 90s. Java doesn't do this, so how is that relevant?
    - monocasa 8y ago
      > Prior to web browsers when was such a thing ever widespread? And if you eliminate web browsers from the picture, how many usages are even left? BPF has existed since the mid 90s for one example. > Java doesn't do this, so how is that relevant? Java and the client web were next to inseparable concepts at the time. Java ran their VM as a shared library in the browser process for applets.
  - stubish 8y ago
    The JVM took responsibility for sandbox isolation. It took until Spectre/Meltdown to widely demonstrate that this was a poor decision, because it turned out in process sandbox isolation is a promise that cannot be kept. And the point of the JVM was to run the same code on all sorts of hardware, so it doesn't get to blame the Intel or Spark or Motorola CPU it happens to be running on.

MiroF 8y ago

Meltdown let processes access kernel memory which was supposed to be hardware protected. That is a violation of the chipmakers obligation, not the software obligation.

tntn 8y ago
... yeah. And that is a different discussion. The article, and the discussion here, is regarding side channels attacks within a single process. I'm pretty sure everyone agrees that the hardware (or some conspiracy of the hardware and kernel) must provide process isolation.