Google Chrome’s new Meltdown and Spectre safeguard is a memory hog | Hacker News Reader

Google Chrome’s new Meltdown and Spectre safeguard is a memory hog

mobilesyrup.com

74 pointscpncrunch54 comments

Given a choice between +10-13% memory use (hardly a “hog”) and a giant gaping security hole, I'll take the former, thanks.

I agree I wouldn't complain given the trade-off, but Chrome is one of the he biggest memory consumer on most people's desktops. A 10-13% increase from one of the biggest process I have running is significant.

If it's causing memory pressure on the system to the point of thrashing, sure. But is that the case or is able to react well to other RAM hungry processes on the system? Not using additional spare memory if it gives the user a better experience seems like a no-no.

Worse is worse. There is no upside to using more memory. You don't know what a given system has for memory, Chrome needs to be as efficient as possible. Chrome is even worse than before with this change. Creating an ideal situation to make Chrome fit is disingenuous.

Hopefully in time they find a way to retain safety without furthering to bloat their browser.

>There is no upside to using more memory.

But there is an upside to better security. It'd be great if it was a free lunch but apparently it's not.

>Chrome needs to be as efficient as possible.

Chrome needs to make its users as happy as possible. Efficiency only matters when it starts affecting user happiness.

>Creating an ideal situation to make Chrome fit is disingenuous.

Do you know that it's an "ideal" situation rather than typical? I don't either but I also suspect Google wouldn't turn this on if it was going to negatively affect most users because they run the risk of losing market share to Safari/Firefox/Edge. I'm open to evidence to the contrary.

>Hopefully in time they find a way to retain safety without furthering to bloat their browser.

That's most likely going to be in the Intel/AMDs court.

> There is no upside to using more memory.

Sure there is. Most complex systems can trade-off between memory usage and CPU. With more memory, the garbage collector doesn't have to work as hard, caches stay warm, etc.

> You don't know what a given system has for memory,

Chrome knows how much memory is available on your system, and it adapts its own memory usage based on this.

V8 is designed to push the garbage collector harder when memory usage is tighter -- reducing usage at the cost of JavaScript running a little slower.

I believe Chrome is also capable of freezing entire background tab states and saving them to disk, to be restored later when you go back to the tab. But there's no reason for it to do that if you have plenty of RAM to spare.

https://en.m.wikipedia.org/wiki/Space–time_tradeoff

Google focuses very strongly on time, so I’m unsurprised that they are willing to trade space for time.

Of course it’s possible Chrome is also outright wasting space, time, or both, but I have no idea if it is to a nontrivial extent.

But maybe I'd like to execute some other programs in addition to Chrome as well. So this might result in unneeded memory pressure in other programs.

That's why you don't use garbage collection. Wasm or static pages only. V8 has been the worst thing to happen to the web, it made JS moderately performant. That's a terrible thing, now we have all this additional complexity thanks to Google's attempt to make the web an appstore.

>Chrome is even worse than before with this change.

That's disingenuous.

Chrome is 1) more secure, but 2) less accessible.

These are separate metrics and you can't really roll them into one.

The article didn't link to the actual blog post: https://security.googleblog.com/2018/07/mitigating-spectre-w... which has some more nuance:

"on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 10-13% total memory overhead in real workloads due to the larger number of processes"

That doesn't even really tell us much.

We need more information. For instance, it would be enlightening to have an understanding of how, exactly, a "real workload" is defined? How many tabs? What's going on in the tabs? Etc. A definition of "real workload" would at least allow us to compare that workload to our own typical workloads. (Which I assume would likely be different for an administrative assistant vs an executive vs a developer vs a researcher vs etc etc etc.)

Headline in an alternate universe: "Google Chrome saves 10% of memory usage by disabling vital security protection"

Alternate headline in our universe: “Chrome increases use of non-constraint resource by 10% to increase security.”

In what world is RAM not constrained? It certainly is in mine.

Headline in alternate universe: "With the powerful computers available in the mid-late 2010s, it is now practical to browse an international web of documents, from your own home!"

Seriously - just this increase is 2x the total memory of a computer I used to browse the internet 20 years ago. People, including programmers, seriously misunderstand how amazingly powerful today's computers are, and how amazingly bloated and inefficient today's applications and websites are.

Couldn't agree more...People were creating universes with 1.44MB on floppies. Instead, Viber desktop app installer, for example, is a 133MB download, ~300MB installed and probably uses double the RAM...

Never mind a universe in 1.44MB; Elite did it in 32KB, albeit with wireframe graphics. [1]

The bloat of many current desktop apps, each with their own copy of a large-footprint GUI toolkit or rendering engine, is indeed sad by comparison. I hope this situation will change when Windows 7 and IE 11 are finally history, meaning that desktop app developers can count on the OS to provide a modern web rendering engine on all platforms.

[1]: https://www.filfre.net/2013/12/elite/

Honest question: The interesting question, IMHO, is not how much Chrome is affected, but how strong the impact is compared to other browsers. Do they suffer similarly? Have they found a way to avoid enlarging the memory footprint? Do they ignore the issue?

(Please tell me it's not number 3!)

https://security.googleblog.com/2018/07/mitigating-spectre-w... says that they've been working on site isolation (one process per domain, so potentially several per tab) for many years. chrome has been multiprocess (process per tab) since day one and it took other browsers years to catch up with being multiprocess. So if other browsers decide to pursue this approach, it'll likely take them years as well. So 3 doesn't seem super unlikely to me :-/

They are not ignoring the issue, but they also do not have this mitigation in place.

Getting there will take a long time. Chrome got lucky - they've been working on this for ages, and they happened to be rolling this out right when Spectre landed.

Firefox is definitely working on this in Project Fission. Bringing down memory per process is crucial and a big focus right now. (I think getting resource sharing down to a science will also be important.)

I'm a fan of Firefox but admit Chrome has an advantage in this situation, while Firefox has had the advantage of resource sharing within the process to keep memory down. Last estimate I saw suggested over a year for it to arrive.

As an illustration of how this approach affects the landscape for all browsers, TechCrunch regularly loads 30 origins on a single page.

It's being actively worked on in Firefox. See e.g. https://groups.google.com/forum/#!topic/mozilla.dev.platform....

Did I miss an announcement where those other competing browsers offered a solution that consumed no additional RAM?

I can't recall any another browser maker introducing a change as encompassing as the Chrome Meltdown and Spectre fix.

"overall memory use in Chrome is higher by 10 to 13 percent when isolating all sites with many tabs open."

I wish chrome would freeze and unload inactive tabs. I may get around to them one day, but there is no need to waste resource on them until then.

The Great Suspender does a pretty good job of this.

https://chrome.google.com/webstore/detail/the-great-suspende...

So what?

Site isolation is a huge win.

Don't blame Google for this. They only did what had to be done in software to fix Intel's hardware flaw. And Intel is currently willing to allow developers to fix many more such Spectre-class flaws in software just so it doesn't have to radically change its architecture.

Maybe Meltdown and Spectre would be a good point to stop and think if an architecture where you run arbitrary turing-complete untrusted code from multiple sources side-by-side and try to mitigate this by locking down the system is really the best direction for the web to move in.

Won't this work become mostly irrelevant in the near future (at least for new hardward)? There is no way all affected software will implement workarounds like this and it this will have to be fixed at the hardware/CPU level in order to fully address it.

I'm sure it's possible to detect if it's fixed in hardware and disable the additional software protection

Not all software is equally affected by this, browsers are particularly affected because they have a JavaScript VM running untrusted code.

But Site Isolation has been in the works in Chrome for a long time and it brings additional protections because it means that exploiting a renderer process doesn't let you break the SOP, which means you absolutely have to break out of the renderer process to have a meaningful exploit - completely removing the renderer codebase from your trusted computing base.

I’m surprised that it took Spectre to get site isolation enabled. Without site isolation, an RCE allows a malicious site to violate the same origin policy even without a sandbox escape. Site isolation is a very nice defense in depth feature.

I’m certainly willing to pay for $10 more memory in exchange for not getting owned.

Will electron apps inherit this increase as well?

They're only one "site", aren't they? So this wouldn't usually be needed?

Unsure about electron but my guess would be that Spotify will certainly inherit this since they chose to use a custom chromium to build on.

Wait. Browsers were a major memory hog even before. Not only Chrome, all of them. Does the extra 10% really matter?

It will matter for some people who were on the edge of swapping but that's probably not so many.

Swapping to what? Firefox uses just as much memory.

Swapping to non-volatile storage? In the context of memory exhaustion I think it was reasonably clear gpp was talking about hitting virtual memory. Although these days faster SSDs make that not quite as dramatic a hit as it once was.

Swapping on SSDs is not ideal though, because of limited number of writes. Is it still relevant with SSDs produced now by the way?

Swapping as in paging.

> Firefox uses just as much memory.

This depends strongly on how many tabs you normally have open. At higher numbers Firefox tends to do much better.

Pretty sure this is explicitly not a Meltdown mitigation, since the whole point of Meltdown is that is allows crossing process boundaries.

Google Chrome is multiprocess.

Right but the whole point of Meltdown (not Sprectre) is that this doesn’t matter.

Yes, you are correct. This is mitigation for Spectre (v1/2/4) but not Meltdown.

Have there been reports yet of an exploit (using Spectre/Meltdown) in the wild?

Yes? There were POCs the day of the announcement.

I think the question is: Has anyone observed it being exploited for actual malicious purposes?

Sure, it's easy to say "of course it has happened, why wouldn't it have?", but it would be really interesting to know how it is actually being used.

That seemed very contrived. For a supposedly fatal flaw that's been lurking in chip designs for tbe better part of a decade, you'd expect real cases.

Chrome has always been a memory hog. For example, the Intel chipset in my machine doesn't support installing more than 4Gb of memory (and I feel that it is artificial limitation to force consumers buy new Intel chipsets) and on top of that, some proprietary 32-bit operating system cannot use more than 3Gb because of so called "PCI hole" - a part of address space that is allocated for PCI devices and cannot be used for accessing memory.

I think that browser developers are making a wrong choice. They increase memory consumption for caches and similar type of data so that complicated and bloated websites work faster; I don't want that. I don't visit such sites anyway and have JS disabled so I would prefer that browser just consumes less memory. Let bloated websites be slow; they deserve it.

Reply on news.ycombinator.com