Hacker News Reader

Comment by sp332 | Hacker News Reader

Many applications don't need Spectre or Meltdown mitigations, but they should at least put the test parameters up front and not in the fine print.

View on HN

Many?

Anything running a browser needs it because of js.

Anything running connected to the internet at all would be well advised to have them because you can take advantage of the exploits via the network stack.

Anything running on a vm has to have them since microcode is set by the hypervisor.

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?

> So, we're talking about desktops not used to browse the internet

You can browse the internet without JS. Many people here seem to do so.

Technically true.

The number of people who do isn't statistically interesting though. If you are I still wouldn't advise doing so while turning off the mitigations since you're still parsing and displaying hostile ip/tcp/http/(html/CSS/image/video/...).

For example, http://www.misc0110.net/web/files/netspectre.pdf

If you're browsing the internet without JS, you don't need a CPU that was built this decade to do so.

Yet, Meltdown is said to probably effect every processor since 25 years ago[1], so I doubt people would have one from before then by chance or be willing to use it.

[1] https://meltdownattack.com/#faq-systems-meltdown

Every Intel processor.

Indeed, I need my CPU for other things that browsing the web.

>Many people here seem to do so.

And many more are ardent that "I should not build a non-js version of my website just for the >1% of users who disable javascript".

Personally I do not disable javascript because it makes huge portions of the web inaccessible, in weird and frustratingly ambiguous ways. But I used to, and I am the kind of person who would again if it were a remote option.

I think it's also possible that the people who do are just much more prone to talking about it. Who talks about how they don't disable javascript unprompted?

I'm not clear what your point was about the VMs. Why do hypervisors need Meltdown mitigated?

I think you're underestimating the % of HPC networks with properly-configured firewalls and only running code from trusted sources.

If you trust all the code (and other inputs, or outputs) on all the VMs, and you are running it in a secure environment, you don't. I admit, it's possible I'm underestimating how common this is.

Why you generally do need it is the above isn't true, and microcode has to be loaded at the hypervisor level for everyone or for no one

> it's possible I'm underestimating how common this is

This is quite common in the engineering/research sectors, which love clusters. Think Sandia, oak ridge, etc. I also personally know of several private companies with research clusters. I'm curious how common hpcs are outside of the research community, because honestly I'm struggling to think of a practical need for one.

HPC is quite common in mechanical engineering type industries. Think mechanical stress simulations, wind simulations, that kind of thing. I wouldn't call that part of the research community.

HPC doesn't generally use VMs or Hypervisors.

HPC is not the real use case (target). The percentage of HPC compared to the rest of the target market (public cloud) is insignificantly small.

The real question is do you trust any potential co-tenants in a public cloud that share a hypervisor with you, when said hypervisor does NOT have Spectre/Meltdown fixes applied? (There is only one correct answer...)

Also you can fairly easily mitigate this in a public cloud setting by running your VM on a dedicated hypervisor. AWS calls these "EC2 Dedicated Instances". Interestingly enough for most compute sizes the cost different is negligable. I imagine that isn't the case everywhere / for-everything, but if you A) need pre-Spectre/Meltdown perf and B) need protection against co-tenancy attacks, paying a few more dollars for a dedicated hypervisor host seems like a no-brainer to me.

HPC is the use case in this thread, considering the topic is revolving around HPC benchmarks.

Let me clarify: When it comes to Spectre/Meltdown, HPC users and environments are most likely not prioritized targets of interest. The low hanging fruit in that scenario is stealing cryptographic keys from co-tenants on a public cloud.

Indeed, and generally HPC doesn't use hypervisors anyways.

> Anything running a browser needs it because of js.

All the javascript engines have implemented spectre and meltdown mitigations.

EDIT: Are the downvotes because people don't believe that the JS mitigations are effective?

> 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.

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.

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.

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?

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.

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.

Many users won't know how to disable Spectre and Meltdown mitigations. They will be active by default if the user installs all the latest updates.

For some reason, I doubt people in the server/workstation space don't know how to do this, especially if they are leaving double digit percentage gains on the table if they don't.

You are not supposed to disable the mitigations... Especially on servers and workstations... And keep in mind that the usual mitigations aren't even holistic. The only truly 100% secure fix for Spectre/Meltdown is to disable hyperthreading altogether.

No. Spectre does not depend on hyperthreading, only speculative execution.

I was lumping them all into MDS class of vulnerabilities. It was misleading.

https://linuxreviews.org/Microarchitectural_Data_Sampling:_T...

Why shouldn't you disable them on servers that don't run Javascript or any other untrusted code?

For servers that aren't running arbitrary third party code, like PaaS or IaaS, why not?

If your server is running baremetal, no problem. If it's running on a shared hosting environment, a co-tenant VM can exfiltrate your data. See L1TF/Foreshadow.

Haven't all the big cloud providers have patched their hypervisors for that?

You really want to rely on such assumptions for security?

It doesn’t keep me up at night.

You absolutely need Spectre/Meltdown mitigation otherwise someone could attack you with JavaScript running in your web browser.

https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(...

   noibrs - We don't need no restricted indirect branch speculation
   noibpb - We don't need no indirect branch prediction barrier either
   nospectre_v1 and nospectre_v2: Don't care if some program can get data from some other program when it shouldn't
   l1tf=off - Why would we be flushing the L1 cache, we might need that data. So what if anyone can get at it.
   nospec_store_bypass_disable - Of course we want to use, not bypass, the stored data
   no_stf_barrier - We don't need no barriers between software, they could be friends
   mds=off - Zombieload attacks are fine
   mitigations=off - Of course we don't want no mitigations

You just leaped to the unfounded conclusion that every computer needs to run untrusted JavaScript. The vast majority of computers have no such need. Especially in a performance-sensitive contest like buying CPU for your database server that lives in a datacenter and never runs a web browser you will certainly disable these security things.

Disabling Spectre/Meltdown mitigations on a server especially would be the dumbest thing imaginable. These attacks are not restricted to JavaScript, they are side-channel attacks and have a huge exploitable surface. Just look at the number of patches for the MS SQL server needed to mitigate:

https://support.microsoft.com/en-us/help/4073225/guidance-pr...

No, it is NOT the dumbest thing imaginable!

If your server is not reachable from untrusted sources, and you are running only what you trust, it is prudent to disable mitigation’s and make use of the extra performance.

Example, I run many compute nodes (only private network) in my HPC cluster with mitigation’s off. If an attacker could reach the compute nodes over the network to push the attack payload, I’ve already been heavily compromised that these attacks are just insult to the injury.

If you run a database server that can never be reached directly by an attacker. You may spend your time watching your application server and let the DB server use the extra oomph.

That's a fascinating take on internal security.

Naturally, everyone must determine their level of risk aversion and take the steps they feel most prudent. I've not heard this perspective before. Thank you for sharing!

It's basically the historical approach to enterprise security: secure the perimeter, and don't worry about the intranet. It's still hugely popular in enterprise IT. Cryptolocker/Wannacry bit these IT departments hard and they've sort of slowly learned some lessons, but there's huge inertia, low budget, and these things are changing glacially.

No, I think you're mixing things up, these two are two distinct things: 1) the old "M&M" approach of securing just the perimeter is basically asking for trouble, but 2) doing proper risk assessment and choosing performance over security for one particular setup.

Scroll down to the table and many paragraphs in which they describe when the various scenarios in which the various mitigations are recommended. That wouldn't be needed at all if not having them was always 'the dumbest thing imaginable'.

Can you point out where Microsoft recommends that you do nothing besides if the user is using "Azure SQL Database and Data Warehouse" (and that's because mitigations are already deployed on their cloud services)?

   Microsoft has deployed mitigations across all our cloud services.

https://docs.microsoft.com/en-us/azure/virtual-machines/wind...

If your threat model is "all the threats all the time" then I assume you also wear a helmet when walking down the street.

I would think the "vast majority" of computers are used interactively by people using Web browsers. Surely the number of servers in the world doesn't massively outnumber clients, and most of the clients browse the Web?

The only applications that will disable these mitigations are maybe home power users or certain niches where access to the system is always trusted. For everyone else, there's performance stealing mitigations.

If you or your employer doesn't apply mitigations I certainly wouldn't go around bragging about it. Let it be a deep, dark secret until the next hw upgrade cycle. Otherwise you'll get pilloried and/or sued for any data breach.

> You just leaped to the unfounded conclusion that every computer needs to run untrusted JavaScript.

You're right about that...

> The vast majority of computers have no such need.

You're probably wrong about that. Every, no. Majority or substantial minority? Yes. There are a ton of consumer computer devices that act as web browsers, and smartphones absolutely count here.

Is there a working JavaScript exploit for Spectre/Meltdown? I though it was just hypothetical.

There was a proof-of-concept included in the whitepaper:

https://spectreattack.com/spectre.pdf

That's a working exploit, not a hypothetical.

A proof-of-concept is not a real world exploit. The PoC operates under perfect conditions.

No, that's not a working exploit, as is said in the paper:

> Chrome intentionally degrades the accuracy of its high-resolution timer to dissuade timing attacks using performance.now() [62]. However, the Web Workers feature of HTML5 makes it simple to create a separate thread that repeatedly decrements a value in a shared memory location [24, 60]. This approach yields a high-resolution timer that provides sufficient resolution.

They did it on Chrome 62.0.3202, but SharedArrayBuffer was disabled in all major browsers right when spectre dropped. Chrome enabled it again in Chrome 67 if Full Site Isolation was enabled. Full site isolation is now enabled by default afaik.

So no, that is in no way a working exploit in any major browser I know of. There is no know spectre (or other variant) exploit that works in a default updated major browser (and there has never been as far as I know), but feel free to link any PoC's.

You're right. When the white paper was announced; it was pre-released to specific entities to work around. The fact that the exploits have since been patched doesn't remove the fact that they were a valid exploit.

Was heartbleed not an exploit because it's since been patched? Or the thousands of DOS TSR viruses? What is even your point or logic here?

All the JS engines have been patched. As far as I'm aware there are no known spectre or meltdown exploits on any of the major JS engines.

No. It's almost unexploitable in the real world. An insanely stupid overreaction that we're all being forced to pay for. Security theatre for the post-Web 2.0 age.

> You absolutely need Spectre/Meltdown mitigation

The article context is HPC - it seems very unlikely Spectre/Meltdown fixes are needed for HPC loads (no browser, no VM sharing).

Not only no VM sharing, but no VMs.

Appliances might be a better word than applications. If you've got a single privilege level (and that itself isn't a security design flaw), yeah, the info leak isn't a problem. HPCish environments are the obvious example.

The chips should be considered defective and "not as advertised" without spectre and meltdown in place.

They fucked up, and are trying to pawn the slowdowns as some sort of Faustian choice.

Reply on news.ycombinator.com