9 ms·

There needs to be a law that protects engineering corporations against security flaws that were previously unknown.

Retric 9y ago
That would simply promote intentional ignorance. Even then Meltdown is part of a known class of attacks namely race conditions, Intel simply messed up.
- AnimalMuppet 9y ago
  They messed up in a way that nobody spotted for a decade. That's not "messing up", that's failing to be psychic.
  - DannyBee 9y ago
    Well, actually, the cache sidechannel timing attacks were fairly well known for quite a while. It's just nobody put two and two together. This is actually mostly due to lack of public information in the processor manuals. Otherwise it's quite likely it would have been discovered 5-6 years ago at least.
    - tarlinian 9y ago
      The fact that modern processors speculatively load memory has been known for a long time (and it's not like the fact that permission checking only occurs during retirement is documented...the reason no one considered it a problem was that it was thought of as an implementation detail and literally something you wouldn't document because in the future you might arbitrarily change it). This isn't exactly novel information...and putting two and two together only seemed obvious after the fact.
      - ahartmetz 9y ago
        Well you know, I always thought accurate rollback was one of the hardest things about speculative execution. But just like other hazards, OF COURSE the CPU vendors have a deep understanding of them and a bag of tricks I have never heard of to avoid them. I am still incredulous about that screwup. It is such an obvious problem. Hey, maybe memory traffic sidebands for speculative execution are next. You can undo cache data changes, you cannot undo the slowing down of simultaneous other memory traffic. And who knows, maybe everyone was like "we cannot prevent all measurable side effects, so screw it #YOLO". And nobody can admit that due to liability issues. That seems quite likely to me because it doesn't involve hundreds of very smart experts missing an obvious problem.
        jnordwick 9y ago
        You don't have to rollback for meltdown. The read can be masked to zero. There is already logic to do things like cancel page walks, so this isn't a very big fix. I think specter should be fixed in software with some assistance from hardware, but overall with ooo, a process shouldn't expect privacy against itself.
        ahartmetz 9y ago
        AFAIU the Spectre software "fixes" are either extremely expensive, or still exploitable, or both. I think you're correct about OOO, and there goes the security of all current HTML/JS engines.
        jnordwick 9y ago
        > Spectre software "fixes" are either extremely expensive They don't have to be done everywhere though. Just on js array accesses and the masking options seem better than the fencing option. It doesn't have to be done on every array access, and i many cases it probably isn't practically exploitable. We still don't have a working, real world exploit in js without assistance. The speculation windows are in practice pretty small (10 instructions maybe), plus you have to find the memory you want to read, mistrain the branch predictor and flush the cpu cache between every read, etc... And do all this before that piece of memory you found moves or is overwritten. > there goes the security of all current HTML/JS engines. Pretty much. In places devs forget to protect against spectre there can be a possible exploit. Ooo causes similarly difficult to find issues with threading where the dev needs to think long and hard about how instructions hit the cpu, but we manage.
  - freehunter 9y ago
    Like DannyBee said, side-channel attacks were well known and security researchers had warned against them since at lest 1995. In fact both MacOS's kernel and the Linux kernel had some basic protections from side-channel attacks for years now, which unfortunately don't work if an attacker can dump the entire contents of all physical RAM. Intel has has a long time to mitigate the issue. They didn't because it made their processors faster, and they chose profits over security.
    - Aloha 9y ago
      That supposes Intel knew about the flaw, and instead did nothing - which I think is a big row to hoe.
      - freehunter 9y ago
        >https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653... Literally since 1995. There's no way Intel hasn't read this report from the NSA detailing how insecure the x86 platform is where they literally call out this exact feature as a security risk. This feature that was not accidental, but intentionally designed. Why exactly are you blindly defending Intel, especially with such easily disprovable arguments?
        tarlinian 9y ago
        Really, the "exact same feature"? None of the processors in that report even support OoOE.
        jnordwick 9y ago
        It isn't the cache side channel that is the important part of meltdown. Flush-reload is just out the information is retrived and ask acceptable problem. The problem is data hitting the cache when it comes from an unreadable page. Meltdown looks like a bug in the cache hit logic because the page information is already in the tlb, and the fix is probably fairly trivial. If the unreadabld page doesnt hit cache or is never mapped there in the first place, spectre can only read its own process.
tomc1985 9y ago
No. Security is already a non-concern amongst non-technical people, who unfortunately control most leadership positions. Protection from liability only means we get to see more, and worse, BS like this in the future. We need to hold companies even more accountable than what they already are. 32 lawsuits is not enough, more like 320!
- sundvor 9y ago
  64 would seem like the logical next step!
- kuschku 9y ago
  2.1161033472192524829557170410776298658794639108376130 * 10^664 lawsuits should definitely be enough to eliminate Intel, yes.
- sannee 9y ago
  Assume you build a product using TLS as the underlying encryption layer. Unfortunately, few months later, some bored mathematician figures out how to completely break AES and ECDH. Should you be held accountable for choosing "weak" ciphers?
  - jnbiche 9y ago
    > Should you be held accountable for choosing "weak" ciphers? That would be up to the jury. For something like your scenario, as long as you're keeping up and using industry best practices, you almost certainly would have nothing to worry about. In fact, a case like that would likely be dismissed immediately by the judge before it ever went to trial.
    - sannee 9y ago
      Okay then, let's assume you are doing something more cutting edge. Like speculative execution involving memory prefetching. What are "industry best practices" for that? There are like 3 companies which do this competitively at scale and each of them guard their methods like it's the Coca-Cola recipe.
JohnJamesRambo 9y ago
Is this satire?

That would simply promote intentional ignorance. Even then Meltdown is part of a known class of attacks namely race conditions, Intel simply messed up.

AnimalMuppet 9y ago
They messed up in a way that nobody spotted for a decade. That's not "messing up", that's failing to be psychic.
- DannyBee 9y ago
  Well, actually, the cache sidechannel timing attacks were fairly well known for quite a while. It's just nobody put two and two together. This is actually mostly due to lack of public information in the processor manuals. Otherwise it's quite likely it would have been discovered 5-6 years ago at least.
  - tarlinian 9y ago
    The fact that modern processors speculatively load memory has been known for a long time (and it's not like the fact that permission checking only occurs during retirement is documented...the reason no one considered it a problem was that it was thought of as an implementation detail and literally something you wouldn't document because in the future you might arbitrarily change it). This isn't exactly novel information...and putting two and two together only seemed obvious after the fact.
    - ahartmetz 9y ago
      Well you know, I always thought accurate rollback was one of the hardest things about speculative execution. But just like other hazards, OF COURSE the CPU vendors have a deep understanding of them and a bag of tricks I have never heard of to avoid them. I am still incredulous about that screwup. It is such an obvious problem. Hey, maybe memory traffic sidebands for speculative execution are next. You can undo cache data changes, you cannot undo the slowing down of simultaneous other memory traffic. And who knows, maybe everyone was like "we cannot prevent all measurable side effects, so screw it #YOLO". And nobody can admit that due to liability issues. That seems quite likely to me because it doesn't involve hundreds of very smart experts missing an obvious problem.
      - jnordwick 9y ago
        You don't have to rollback for meltdown. The read can be masked to zero. There is already logic to do things like cancel page walks, so this isn't a very big fix. I think specter should be fixed in software with some assistance from hardware, but overall with ooo, a process shouldn't expect privacy against itself.
        ahartmetz 9y ago
        AFAIU the Spectre software "fixes" are either extremely expensive, or still exploitable, or both. I think you're correct about OOO, and there goes the security of all current HTML/JS engines.
        jnordwick 9y ago
        > Spectre software "fixes" are either extremely expensive They don't have to be done everywhere though. Just on js array accesses and the masking options seem better than the fencing option. It doesn't have to be done on every array access, and i many cases it probably isn't practically exploitable. We still don't have a working, real world exploit in js without assistance. The speculation windows are in practice pretty small (10 instructions maybe), plus you have to find the memory you want to read, mistrain the branch predictor and flush the cpu cache between every read, etc... And do all this before that piece of memory you found moves or is overwritten. > there goes the security of all current HTML/JS engines. Pretty much. In places devs forget to protect against spectre there can be a possible exploit. Ooo causes similarly difficult to find issues with threading where the dev needs to think long and hard about how instructions hit the cpu, but we manage.
- freehunter 9y ago
  Like DannyBee said, side-channel attacks were well known and security researchers had warned against them since at lest 1995. In fact both MacOS's kernel and the Linux kernel had some basic protections from side-channel attacks for years now, which unfortunately don't work if an attacker can dump the entire contents of all physical RAM. Intel has has a long time to mitigate the issue. They didn't because it made their processors faster, and they chose profits over security.
  - Aloha 9y ago
    That supposes Intel knew about the flaw, and instead did nothing - which I think is a big row to hoe.
    - freehunter 9y ago
      >https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653... Literally since 1995. There's no way Intel hasn't read this report from the NSA detailing how insecure the x86 platform is where they literally call out this exact feature as a security risk. This feature that was not accidental, but intentionally designed. Why exactly are you blindly defending Intel, especially with such easily disprovable arguments?
      - tarlinian 9y ago
        Really, the "exact same feature"? None of the processors in that report even support OoOE.
      - jnordwick 9y ago
        It isn't the cache side channel that is the important part of meltdown. Flush-reload is just out the information is retrived and ask acceptable problem. The problem is data hitting the cache when it comes from an unreadable page. Meltdown looks like a bug in the cache hit logic because the page information is already in the tlb, and the fix is probably fairly trivial. If the unreadabld page doesnt hit cache or is never mapped there in the first place, spectre can only read its own process.

tomc1985 9y ago

No. Security is already a non-concern amongst non-technical people, who unfortunately control most leadership positions. Protection from liability only means we get to see more, and worse, BS like this in the future. We need to hold companies even more accountable than what they already are. 32 lawsuits is not enough, more like 320!

sundvor 9y ago
64 would seem like the logical next step!
kuschku 9y ago
2.1161033472192524829557170410776298658794639108376130 * 10^664 lawsuits should definitely be enough to eliminate Intel, yes.
sannee 9y ago
Assume you build a product using TLS as the underlying encryption layer. Unfortunately, few months later, some bored mathematician figures out how to completely break AES and ECDH. Should you be held accountable for choosing "weak" ciphers?
- jnbiche 9y ago
  > Should you be held accountable for choosing "weak" ciphers? That would be up to the jury. For something like your scenario, as long as you're keeping up and using industry best practices, you almost certainly would have nothing to worry about. In fact, a case like that would likely be dismissed immediately by the judge before it ever went to trial.
  - sannee 9y ago
    Okay then, let's assume you are doing something more cutting edge. Like speculative execution involving memory prefetching. What are "industry best practices" for that? There are like 3 companies which do this competitively at scale and each of them guard their methods like it's the Coca-Cola recipe.

JohnJamesRambo 9y ago

Is this satire?