3 ms·

> So, we're talking about desktops not used to browse the internet, and bare metal servers whose network stacks aren't exposed to hostile actors? To be fair th

> So, we're talking about desktops not used to browse the internet, and bare metal servers whose network stacks aren't exposed to hostile actors? To be fair the context here is HPC. Nobody is installing Chrome on something like IBM's Summit supercomputer. Nor is it running "untrusted" code. It's configured to go as fast as possible, nothing more. Anyone in cloud hosting or desktop would be insane to not install spectre/meltdown fixes. But in this particular niche of HPC supercomputers it's actually reasonable to not have those mitigations.

snoman 7y ago
Is it though? There's a significant security bug that has a known fix, on your supercomputer. The second anything remotely security-related happens and it gets out that you've opted to hedge your bets that no untrusted code will ever execute on that machine... and you could be in some seriously hot water. I'm not really in the HPC space, but I can't really see any vp/cto/cio reasonably putting that asterisk on a security audit. If you've got cyber insurance, you probably wouldn't be able to keep coverage if you did that.
- zepearl 7y ago
  I agree - factors involving insurance, compliance, auditing, etc... will play a big role for any company using such systems to process any kind of even slightly confidential information. Any CIO that decides not to use such security patches will carry on his/her shoulders the full risk. Big bosses don't like risk and like even less to be personally accountable for anything => I don't see that happening. Even if the tests mentioned in the article might be related to HPC, the HW is for general computing therefore its usage doesn't have to be restricted to HPC, but people might still decide to use (as well) those HPC-results to compare the types of CPUs.
- kllrnohj 7y ago
  What do you think is the actual risk? Who is attacking whom, and how? If you're running on HPC you basically rented the hardware. It's a time-share system. The entire thing is yours, all yours, for the hours you managed to procure. So who are you attacking? And what vp/cto/cio are you even talking about? The ones who own the hardware, or the ones who are renting it? And why do you think a security policy is needed here at all instead of just, you know, laws & contracts? You can't just anonymously rent time on these systems even if you have the money - you need your usage approved, too, and it's a big whole process. If you then go and successfully launch a security attack, why does that require technical safeguards instead of just the FBI knocking down your door and hauling your ass to jail?
tagrun 7y ago
Except HPC clusters do need all the Spectre/Meltdown fixes and more. Those are shared environments (with the exception of a handful of people who got research grants for their own internal clusters). In fact, hyper-threading has also been disabled completely is some clusters.
- sliken 7y ago
  I'm sure there are some, I'd be very surprised it it was most though. The main problem with Spectre/Meltdown and friends is two VPSs under the same hypervisor sharing a core running some webstack. With careful analysis of tlb, cache timings, and related you can extract SSL private keys, bitcoin addresses, and similar information that would normally be quite hidden since you are running in a different kernels sharing the same hardware. With a HPC cluster you are (generally) running on bare metal (no hypervisor), single linux kernel, and can see what the other user (if there is one) with simple tools like ps, w, top, and friends. Additionally there's generally not private keys for SSL or bitcoin addresses. In fact often unencrypted network filesystems are used sending plain text over the wire. Even on more sensitive clusters the security is highest between the internet and the head node and less so between compute nodes. Hyperthreading being on vs off is usually just an issue with the performance characteristics of whatever application is most common and the limitations of certain batch queues like sun grid engine (SGE). If your popular app hates hyperthreading then you turn it off. Or sometimes you want to minimize the performance impact of users sharing a core. Additionally sometimes cores, or even nodes are not shared. But again it's for performance reasons not security. Last thing you want is a 10,000 core job to run 50% as fast because one node is shared with a resource intensive application.

snoman 7y ago

Is it though? There's a significant security bug that has a known fix, on your supercomputer. The second anything remotely security-related happens and it gets out that you've opted to hedge your bets that no untrusted code will ever execute on that machine... and you could be in some seriously hot water. I'm not really in the HPC space, but I can't really see any vp/cto/cio reasonably putting that asterisk on a security audit. If you've got cyber insurance, you probably wouldn't be able to keep coverage if you did that.

zepearl 7y ago
I agree - factors involving insurance, compliance, auditing, etc... will play a big role for any company using such systems to process any kind of even slightly confidential information. Any CIO that decides not to use such security patches will carry on his/her shoulders the full risk. Big bosses don't like risk and like even less to be personally accountable for anything => I don't see that happening. Even if the tests mentioned in the article might be related to HPC, the HW is for general computing therefore its usage doesn't have to be restricted to HPC, but people might still decide to use (as well) those HPC-results to compare the types of CPUs.
kllrnohj 7y ago
What do you think is the actual risk? Who is attacking whom, and how? If you're running on HPC you basically rented the hardware. It's a time-share system. The entire thing is yours, all yours, for the hours you managed to procure. So who are you attacking? And what vp/cto/cio are you even talking about? The ones who own the hardware, or the ones who are renting it? And why do you think a security policy is needed here at all instead of just, you know, laws & contracts? You can't just anonymously rent time on these systems even if you have the money - you need your usage approved, too, and it's a big whole process. If you then go and successfully launch a security attack, why does that require technical safeguards instead of just the FBI knocking down your door and hauling your ass to jail?

tagrun 7y ago

Except HPC clusters do need all the Spectre/Meltdown fixes and more. Those are shared environments (with the exception of a handful of people who got research grants for their own internal clusters). In fact, hyper-threading has also been disabled completely is some clusters.

sliken 7y ago
I'm sure there are some, I'd be very surprised it it was most though. The main problem with Spectre/Meltdown and friends is two VPSs under the same hypervisor sharing a core running some webstack. With careful analysis of tlb, cache timings, and related you can extract SSL private keys, bitcoin addresses, and similar information that would normally be quite hidden since you are running in a different kernels sharing the same hardware. With a HPC cluster you are (generally) running on bare metal (no hypervisor), single linux kernel, and can see what the other user (if there is one) with simple tools like ps, w, top, and friends. Additionally there's generally not private keys for SSL or bitcoin addresses. In fact often unencrypted network filesystems are used sending plain text over the wire. Even on more sensitive clusters the security is highest between the internet and the head node and less so between compute nodes. Hyperthreading being on vs off is usually just an issue with the performance characteristics of whatever application is most common and the limitations of certain batch queues like sun grid engine (SGE). If your popular app hates hyperthreading then you turn it off. Or sometimes you want to minimize the performance impact of users sharing a core. Additionally sometimes cores, or even nodes are not shared. But again it's for performance reasons not security. Last thing you want is a 10,000 core job to run 50% as fast because one node is shared with a resource intensive application.