4 ms·

You are right, I sort of misread the statement I was replying to, but also wanted to reinforce that the large class of personal desktop machines is still very m

by anyfoo 1y ago

You are right, I sort of misread the statement I was replying to, but also wanted to reinforce that the large class of personal desktop machines is still very much affected, even if you "think" that you don't run "arbitrary code" on your machine. By the way, you have to be careful on your database server to not actually run arbitrary code as well. If your database supports stored procedures (think PL/SQL), that qualifies, if the clients that are able to create the stored procedures are not supposed to be able to access all data on that server anyway.

baobun 1y ago
Oh yeah. Supply-chain risk is still a thing too and defense-in-depth is not a bad strategy. Physical isolation simplifies a lot of this. This class of attacks isn't (as) relevant for single-tenant single-workload dedicated machines.
- vlovich123 1y ago
  Based on this thread, I think people badly misjudge what “single-tenant” means in the context of susceptibility to exploits.
  - baobun 1y ago
    Mind elaborating?
    - vlovich123 1y ago
      Your “infrastructure” server could be a CI server - it’s just building “my” code ignoring that many (all?) build systems allow execution of arbitrary code as part of the build process (rust, cmake, bazel, JS ecosystem, Go, etc etc) and many involve 3p dependencies. And CI servers often handle secrets to infrastructure (publishing packages, etc). So you could end up allowing a supply chain attack that reads out various API keys & whatnot. In other words, properly drawing the boundary around “this is safe with meltdown disabled” is very hard, non-intuitive, and you’re one configuration/SW change or a violated assumption away from a Meltdown attack which is cross-process memory access & one notch below remote access. There’s a reason you design for security in depth rather than trying to carefully build a jenga tower where you’re one falling block away from total compromise.

by anyfoo 1y ago

baobun 1y ago

Oh yeah. Supply-chain risk is still a thing too and defense-in-depth is not a bad strategy. Physical isolation simplifies a lot of this. This class of attacks isn't (as) relevant for single-tenant single-workload dedicated machines.

vlovich123 1y ago
Based on this thread, I think people badly misjudge what “single-tenant” means in the context of susceptibility to exploits.
- baobun 1y ago
  Mind elaborating?
  - vlovich123 1y ago
    Your “infrastructure” server could be a CI server - it’s just building “my” code ignoring that many (all?) build systems allow execution of arbitrary code as part of the build process (rust, cmake, bazel, JS ecosystem, Go, etc etc) and many involve 3p dependencies. And CI servers often handle secrets to infrastructure (publishing packages, etc). So you could end up allowing a supply chain attack that reads out various API keys & whatnot. In other words, properly drawing the boundary around “this is safe with meltdown disabled” is very hard, non-intuitive, and you’re one configuration/SW change or a violated assumption away from a Meltdown attack which is cross-process memory access & one notch below remote access. There’s a reason you design for security in depth rather than trying to carefully build a jenga tower where you’re one falling block away from total compromise.