Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New speculative attacks on Apple CPUs

predictors.fail

Post reply on HN
Print view View original

231–240 of 365 posts

Re: New speculative attacks on Apple CPUs

#231

Post by BobbyTables2 »

lxgr wrote: post #69
omcnoe wrote: post #63

Earlier quoted context omitted.

Cross-Origin-Opener-Policy seems like a case of bad defaults where a less secure option has been selected so that we don't break some poorly maintained websites. Better to get the actual users of `window.open` to fix their code than to make every website insecure out of the box. I can't imagine there are many sites passing significant amounts of data through this, the small number of users where IPC poses too high a…

Forcing every website to adapt to a browser update is completely infeasible. > I can't imagine there are many sites passing significant amounts of data through this This is actually a quite common mechanism for popup-based authentication (which is much more secure than iframe-based one, as users can verify where they're potentially entering their credentials).

Expecting websites to defend themselves against CPU side channel attacks is also absurd!

Re: New speculative attacks on Apple CPUs

#232

Post by School-Cotton »

aucisson_masque wrote: post #207

> As pointed out by iLeakage, Safari lacks Site Isolation Well I'm shocked, for such a company that promotes security and privacy, apple not having put site isolation into safari seems amateurish.

Apple promotes privacy, sure. I'm not sure whether they promote security. Of course they are not against security, but I don't remember it being a significant theme in their marketing.

Re: New speculative attacks on Apple CPUs

#233

Post by astrange »

lxgr wrote: post #166
astrange wrote: post #140

Earlier quoted context omitted.

Have you noticed how often people complain Chrome uses too much memory?

Process-per-site isolation doesn't necessarily have to use (much) more memory. If you pre-initialize the renderer and JavaScript engine and then fork that pre-warmed instance for each site, every page of memory not written to remains shared in physical memory. Properly accounting for that in task managers is hard, though; on many OSes, Chrome's memory usage looks much scarier than it is in reality.

You can't fork a GUI process on Apple OSes, most of the system can't handle it.

It'd also weaken any security protection based on randomness (eg ASLR slide, pointer encryption keys).

Re: New speculative attacks on Apple CPUs

#234

Post by fennecbutt »

lxgr wrote: post #188
amatecha wrote: post #186

Earlier quoted context omitted.

idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous). The amount of obscure APIs being added just boosts the surface area for vulnerabilities and makes low-resource web browsing nearly impossible. You either get "a web browser that works" or "a web browse…

Well, for better or worse, the web is an application platform these days. I consider it pretty great, since the alternative is installing native apps for things I'm using exactly once or very rarely. There's a case to be made though that maybe these things should only be available to PWAs, which is what Apple is already doing for some functionality on iOS, including push notifications.

What? I thought Apple was trying to quietly kill pwas, probably bc they don't go thru their app store. And also bc if you make a good enough sandbox then you don't need to pay for "all the wooork we put in"

Re: New speculative attacks on Apple CPUs

#235

Post by astrange »

avianlyric wrote: post #206
anyfoo wrote: post #145

Earlier quoted context omitted.

There are usually no valid 32 bit addresses, i.e. the first 4GB are not mapped.

That might be their point. As the OP quoted > any virtual address below 0x100, 000, 000 is invalid. That kinda suggests that all 32bit addresses are inherently invalid on 64bit MacOS

Not inherently, it's just a linker default. You can run 32-bit processes through WINE.

Re: New speculative attacks on Apple CPUs

#236

Post by astrange »

avianlyric wrote: post #211
daneel_w wrote: post #157

Earlier quoted context omitted.

It's a common misunderstanding that the CPU suddenly has twice as large performance envelope when SMT is enabled. Only specialized software/scenarios will tangibly benefit from the parasitic gains of SMT-induced extra parallelization, e.g. video encoders like x264 or CPU-bound raytracers to name a few examples. These gains typically amount to about 15-20% at the very extreme end. In some cases you'll see a performanc…

Are you sure about your statement > video encoders like x264 or CPU-bound raytracers to name a few examples. These gains typically amount to about 15-20% at the very extreme end. Normally those types of compute heavy processes, data streamlined, processes don’t see much benefit from SMT. After all SMT only provides a performance benefit by allowing the CPU to pull from two distinct chains of instructions, and fill th…

Compression is inherently unpredictable (if you can predict it, it's not compressed enough), which is vaguely speaking how it can help x264.

Re: New speculative attacks on Apple CPUs

#237

Post by ChadNauseam »

amatecha wrote: post #186
kergonath wrote: post #158

Earlier quoted context omitted.

> Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites. And then we get thousands of posts whining about Safari being broken because it is "not like Chrome" and developers moaning that their unsafe pet API is not supported. Web developers are never going to play ball.

idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous). The amount of obscure APIs being added just boosts the surface area for vulnerabilities and makes low-resource web browsing nearly impossible. You either get "a web browser that works" or "a web browse…

Every web developer is fine with 10% of the feature set, it’s just a different 10% for each dev. I am regularly annoyed by the inconsistent browser support for Web MIDI, something 99% of web devs probably don’t care about at all.

It would be easier to sandbox if there were fewer features of course, but in practice we rarely see exploits even in complicated low-level APIs like webgpu (which must be a nightmare to make secure given how many buggy drivers and different devices it has to support). So it seems like in practice we are able to sandbox these APIs securely, and having them provides an incredible benefit to users who are able to securely and easily run applications (how else do you recommend people do this on desktop platforms?).

Re: New speculative attacks on Apple CPUs

#238

Post by autoexec »

fsflover wrote: post #164
autoexec wrote: post #122

Earlier quoted context omitted.

It's a tragedy that so many websites insist on having the ability to run random downloaded code on our systems to do basic things like displaying simple text and images. Things browsers are capable of with nothing but HTML. Google refuses to even show search results, a bunch of literal hyperlinks, without javascript being enabled.

> Google refuses to even show search results, a bunch of literal hyperlinks, without javascript being enabled. DuckDuckGo works fine with no JS.

It mostly works. I get a lot of "No results." and !images doesn't work

Re: New speculative attacks on Apple CPUs

#240

Post by lxgr »

astrange wrote: post #233
lxgr wrote: post #166

Earlier quoted context omitted.

Process-per-site isolation doesn't necessarily have to use (much) more memory. If you pre-initialize the renderer and JavaScript engine and then fork that pre-warmed instance for each site, every page of memory not written to remains shared in physical memory. Properly accounting for that in task managers is hard, though; on many OSes, Chrome's memory usage looks much scarier than it is in reality.

You can't fork a GUI process on Apple OSes, most of the system can't handle it. It'd also weaken any security protection based on randomness (eg ASLR slide, pointer encryption keys).

Huh, TIL Chrome on macOS might actually not be using the “zygote process” paradigm!

https://source.chromium.org/chromium/chromium/src/+/main:con...

Post reply on HN