3 ms·

This is an unreasonable position. Vulnerabilities can be fixed

layer8 3y ago
You are assuming that white hats discover them early enough before black hats.
2OEH8eoCRo0 3y ago
The mitigation here can incur a whopping 50% performance penalty. At what point can customers return these CPUs for either being defective or sue for false advertising? If they can't safely meet the target performance they shouldn't be doing these tricks at all.
- dcow 3y ago
  Did processor companies ever advertise that processors guaranteed certain security properties of the software they execute? Aren't system designers at fault for coming up with the idea of a context switch and assuming that we can trust a processor not to leak details across artificial software constructed boundaries?
  - rvnx 3y ago
    But wait, how is it even considered a processor bug ? You write data inside the registers, yes, other processes can read these registers. It always been like this, and is absolutely normal. It's the responsibility of the operating system to clear the registers if it is switching context.
    - deleted 3y ago
      [deleted]
    - duped 3y ago
      > But wait, how is it even considered a processor bug ? These side channel attacks allow an attacker to read registers from other processes before any context switching has occurred, or independently of any context switching (even if the OS has been written to correctly clear state).
  - 3np 3y ago
    According to OP, SGX is also vulnerable. There has been quite some marketing around the supposed security properties of SGX, yes.
  - IlliOnato 3y ago
    Yeah, I am sure the customers can sue, but would they win? I find it unlikely.
    - CanaryLayout 3y ago
      AMD has the same problem (Inception). Predictive instruction pipelining makes timing and context separation harder. Even if you are on s390x or M1 it's not like you are safe either. This is a whole field of study. In my mind the better mitigation is to put control over trusted code back to the user and to do that you have to add less-performant cores onto the die and force the operator to elevate (or not) to SMT. Right now it's an all-or-nothing proposition for the whole board. I would like to think that you can take your untrusted code and stick it on the less-performy cores with the safer instruction pipelining scheme so an actual physical barrier exists. If that was in the chip architecture, then it's up to OS vendors to surface it in a way that developers understand, and then down to the operator to decide upon configuration. You are never going to get a perfect-solve from the chipmakers on this where the consumer has to do nothing.
  - CanaryLayout 3y ago
    > Aren't system designers at fault for coming up with the idea of a context switch Context switching was in the Apollo 11 guidance computer https://www.youtube.com/watch?v=xx7Lfh5SKUQ https://www.youtube.com/watch?v=xx7Lfh5SKUQ The problem is that cycle-speed boosts left the industry cic. 2012-or-so. All the perf boost we get these days is by optimizing the instruction sequencing and multiprocessing. This is why languages like Go popped up (making the advanced programming topic of multiprogramming an entry-level accomplishment) and you now see the 'async' decorator plastered everywhere in C#, and so-on. Keeping the security context intact and separated is a gargantuan task. To me it makes more sense to add "lousy cores" to the die and force the operator to declare the launching threads are safe for SMT, else the job gets scheduled to the less-performing core where the pipelining is safer. It delegates responsibility to the chip-gobbler, forces them to understand the tradeoff for performance, until some elegant solution is found for side channel attacks like this.
  - autoexec 3y ago
    > Did processor companies ever advertise that processors guaranteed certain security properties It's not the guaranteed security as much as the advertised speed that's the issue. If they put out a chip which could only be used at half the advertised speed or else it would catch on fire, nobody would argue that they should be let off the hook because they didn't guarantee that the chips were fireproof in their ads. If the chips can't perform at advertised speeds safely during typical use they're not delivering what was advertised.
    - dcow 3y ago
      They do perform at the advertised speeds, just not in a multi-user soft context switched situations.
hinkley 3y ago
Vulnerabilities are like unreliable cars. It doesn't matter so much if they can be fixed, it's the very, very high opportunity cost of needing to be fixed, when you were busy doing something else of high value. Responsible people tend to pick the small consequence now over the unknowable distribution of consequences later.
pseudalopex 3y ago
> Vulnerabilities can be fixed Not always the damage.
jjav 3y ago
> This is an unreasonable position. Vulnerabilities can be fixed That's a highly optimistic position, to the point of being almost wishful thinking. The vulnerability being talked about today has been around since 2014 according to the report. Possibly being exploited for unknown number of years since. Sure, maybe we can workaround this one, now. Other similar ones to be published years into the future are also there today being likely exploited as we speak. Running untrusted code on the same silicon as sensitive code (data), is unlikely to ever actually be truly safe.
- alerighi 3y ago
  The real problem here is the x86 architecture. We should stop using it. It's too complex, it's full of stuff made for backward compatibility purposes, it has too many instructions that may have unpredictable results, and for that exact reason it's extremely difficult to get things right. Somewhere in the thousands of instructions that it has you will surely find a bug. We should move forward. Apple did a great job with the M{1,2} processors. Not only they are fantastic in terms of performance and energy usage, but also (to this moment) they don't seem to suffer from these issues. The reason is that the CPU is simpler, and a simpler thing is easy to design right in the first place.
  - pseudalopex 3y ago
    Meltdown and Spectre affected ARM and POWER CPUs. Apple's included. PACMAN affected M1. The real problem is speculative execution seemingly.
    - CanaryLayout 3y ago
      Performance sorta hinges on it. It could be that the cheaper way the chipmakers deal with it is to phase out the 4core set and push the cores on a die higher, and to do that--incorporate an older core design into dedicated cores for untrusted code. This would also require changes at the OS-makers to tag thread forks for trusted and untrusted behavior. Essentially: instead of shutting down SMT for the entire machine, make the customer "prove" the code is safe for elevation or else it gets scheduled as non-SMT.

You are assuming that white hats discover them early enough before black hats.

The mitigation here can incur a whopping 50% performance penalty. At what point can customers return these CPUs for either being defective or sue for false advertising? If they can't safely meet the target performance they shouldn't be doing these tricks at all.

dcow 3y ago
Did processor companies ever advertise that processors guaranteed certain security properties of the software they execute? Aren't system designers at fault for coming up with the idea of a context switch and assuming that we can trust a processor not to leak details across artificial software constructed boundaries?
- rvnx 3y ago
  But wait, how is it even considered a processor bug ? You write data inside the registers, yes, other processes can read these registers. It always been like this, and is absolutely normal. It's the responsibility of the operating system to clear the registers if it is switching context.
  - deleted 3y ago
    [deleted]
  - duped 3y ago
    > But wait, how is it even considered a processor bug ? These side channel attacks allow an attacker to read registers from other processes before any context switching has occurred, or independently of any context switching (even if the OS has been written to correctly clear state).
- 3np 3y ago
  According to OP, SGX is also vulnerable. There has been quite some marketing around the supposed security properties of SGX, yes.
- IlliOnato 3y ago
  Yeah, I am sure the customers can sue, but would they win? I find it unlikely.
  - CanaryLayout 3y ago
    AMD has the same problem (Inception). Predictive instruction pipelining makes timing and context separation harder. Even if you are on s390x or M1 it's not like you are safe either. This is a whole field of study. In my mind the better mitigation is to put control over trusted code back to the user and to do that you have to add less-performant cores onto the die and force the operator to elevate (or not) to SMT. Right now it's an all-or-nothing proposition for the whole board. I would like to think that you can take your untrusted code and stick it on the less-performy cores with the safer instruction pipelining scheme so an actual physical barrier exists. If that was in the chip architecture, then it's up to OS vendors to surface it in a way that developers understand, and then down to the operator to decide upon configuration. You are never going to get a perfect-solve from the chipmakers on this where the consumer has to do nothing.
- CanaryLayout 3y ago
  > Aren't system designers at fault for coming up with the idea of a context switch Context switching was in the Apollo 11 guidance computer https://www.youtube.com/watch?v=xx7Lfh5SKUQ https://www.youtube.com/watch?v=xx7Lfh5SKUQ The problem is that cycle-speed boosts left the industry cic. 2012-or-so. All the perf boost we get these days is by optimizing the instruction sequencing and multiprocessing. This is why languages like Go popped up (making the advanced programming topic of multiprogramming an entry-level accomplishment) and you now see the 'async' decorator plastered everywhere in C#, and so-on. Keeping the security context intact and separated is a gargantuan task. To me it makes more sense to add "lousy cores" to the die and force the operator to declare the launching threads are safe for SMT, else the job gets scheduled to the less-performing core where the pipelining is safer. It delegates responsibility to the chip-gobbler, forces them to understand the tradeoff for performance, until some elegant solution is found for side channel attacks like this.
- autoexec 3y ago
  > Did processor companies ever advertise that processors guaranteed certain security properties It's not the guaranteed security as much as the advertised speed that's the issue. If they put out a chip which could only be used at half the advertised speed or else it would catch on fire, nobody would argue that they should be let off the hook because they didn't guarantee that the chips were fireproof in their ads. If the chips can't perform at advertised speeds safely during typical use they're not delivering what was advertised.
  - dcow 3y ago
    They do perform at the advertised speeds, just not in a multi-user soft context switched situations.

hinkley 3y ago

Vulnerabilities are like unreliable cars. It doesn't matter so much if they can be fixed, it's the very, very high opportunity cost of needing to be fixed, when you were busy doing something else of high value. Responsible people tend to pick the small consequence now over the unknowable distribution of consequences later.

pseudalopex 3y ago

> Vulnerabilities can be fixed Not always the damage.

jjav 3y ago

> This is an unreasonable position. Vulnerabilities can be fixed That's a highly optimistic position, to the point of being almost wishful thinking. The vulnerability being talked about today has been around since 2014 according to the report. Possibly being exploited for unknown number of years since. Sure, maybe we can workaround this one, now. Other similar ones to be published years into the future are also there today being likely exploited as we speak. Running untrusted code on the same silicon as sensitive code (data), is unlikely to ever actually be truly safe.

alerighi 3y ago
The real problem here is the x86 architecture. We should stop using it. It's too complex, it's full of stuff made for backward compatibility purposes, it has too many instructions that may have unpredictable results, and for that exact reason it's extremely difficult to get things right. Somewhere in the thousands of instructions that it has you will surely find a bug. We should move forward. Apple did a great job with the M{1,2} processors. Not only they are fantastic in terms of performance and energy usage, but also (to this moment) they don't seem to suffer from these issues. The reason is that the CPU is simpler, and a simpler thing is easy to design right in the first place.
- pseudalopex 3y ago
  Meltdown and Spectre affected ARM and POWER CPUs. Apple's included. PACMAN affected M1. The real problem is speculative execution seemingly.
  - CanaryLayout 3y ago
    Performance sorta hinges on it. It could be that the cheaper way the chipmakers deal with it is to phase out the 4core set and push the cores on a die higher, and to do that--incorporate an older core design into dedicated cores for untrusted code. This would also require changes at the OS-makers to tag thread forks for trusted and untrusted behavior. Essentially: instead of shutting down SMT for the entire machine, make the customer "prove" the code is safe for elevation or else it gets scheduled as non-SMT.