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

291–300 of 365 posts

Re: New speculative attacks on Apple CPUs

#291

Post by iggldiggl »

withinboredom wrote: post #279
amatecha wrote: post #254

Earlier quoted context omitted.

Dunno, that API has only been available since Firefox 126 and I've been watching videos without having my screen go to sleep (or screensaver coming on) for like.. years and years (far before Firefox 126)

That's because there used to be this thing called flash/silverlight that could do this instead. Now, video is done completely differently than it was.

> Now, video is done completely differently than it was.

Which is a thing that happened long before Firefox 126, too. (Browsers have simply requested the screen wakelock themselves when a video was playing. So this API is mainly for use cases that aren't playing a video.)

Re: New speculative attacks on Apple CPUs

#292

Post by aucisson_masque »

School-Cotton wrote: post #232
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.

I believe it's implied when they say 'what happens on your iphone stays on your iphone'.

You can have security without privacy but you can't have privacy without security, when they promote privacy they also claim to be secure.

No website isolation goes against both of these principles.

Re: New speculative attacks on Apple CPUs

#293

Post by hashstring »

prmoustache wrote: post #289
hashstring wrote: post #223

Earlier quoted context omitted.

What about turn JS off on your favourite iOS browser?

That wouldn't prevent possible malware apps using WKWebview from getting out of the jail they are running out right?

Yes, I agree.

However I also expect that Swift-compiled apps can do this without a web browser component.

It’s a different threat model though, having installed a malicious app vs browsing a malicious site.

Re: New speculative attacks on Apple CPUs

#294

Post by fsflover »

MikeHolman wrote: post #260
lxgr wrote: post #215

Earlier quoted context omitted.

Can't edit my original post anymore: Firefox and Chrome do seem to isolate even same-browsing-context-group and bridge the required APIs via IPC, so hopefully Safari will catch up at some point. Basically, there are three scenarios: - Completely unrelated tabs (e.g. those you open manually, those opened via command-click, tabs opened via ' " or 'rel="noopener"' references etc.) – these are relatively easily isolated…

I worked on a browser team when Spectre/Meltdown came out, and I can tell you that a big reason why Firefox and Chrome do such severe process isolation is exactly because these speculative attacks are almost impossible to entirely prevent. There were a number of other mitigations including hardening code emitted from C++ compilers and JS JITs, as well as attempts to limit high precision timers, but the browser vendor…

> I'm not surprised to see this come back to bite them if after like 7 years Apple still hasn't adopted the only strong defense.

So the Apple's argument that iOS can't have alternative browsers for security is a lie.

Re: New speculative attacks on Apple CPUs

#295

Post by padenot »

amatecha wrote: post #254
not_kurt_godel wrote: post #242

Earlier quoted context omitted.

> The Screen Wake Lock API provides a way to prevent devices from dimming or locking the screen when an application needs to keep running. https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake ... There's an obscure use case for this called "Watching Video"

Dunno, that API has only been available since Firefox 126 and I've been watching videos without having my screen go to sleep (or screensaver coming on) for like.. years and years (far before Firefox 126)

Indeed. I work on the Firefox media stack and we have been grabbing wake locks when video playback is happening for a long time. Occasionally e.g. on some linux desktop variant this has malfunctioned and we're alerted in no time and fix it.

The Wake Lock API is for other use cases, such as recipe websites, or other document for which you don't want the screen to go away / dim, the kind where you happen to need to look at the screen for long period of time without touching it/interacting w/ mouse and keyboard.

Prior to this API being introduced, websites used to play an inaudible/almost invisible looping media file to keep the screen awake. This has power usage implication, a small single digit number of watts (1 to 3.5 depending on os, hardware, mobile or not) is required to keep audio running (because of high priority threads, frequent wakeups, and simply because the audio hardware itself needs power).

One of those libraries source, for illustration: https://github.com/richtr/NoSleep.js/blob/master/src/index.j...

Re: New speculative attacks on Apple CPUs

#296

Post by rasz »

alphabetting wrote: post #189

Is the statement from Apple just PR or is this not a usable exploit? "Based on our analysis, we do not believe this issue poses an immediate risk to our users." https://www.bleepingcomputer.com/news/security/new-apple-cpu...

>statement from Apple just PR

remember the iphone 6 battery and butterfly keyboard gate we both "small number of users" according to Apple.

Re: New speculative attacks on Apple CPUs

#297

Post by prmoustache »

hashstring wrote: post #293
prmoustache wrote: post #289

Earlier quoted context omitted.

That wouldn't prevent possible malware apps using WKWebview from getting out of the jail they are running out right?

Yes, I agree. However I also expect that Swift-compiled apps can do this without a web browser component. It’s a different threat model though, having installed a malicious app vs browsing a malicious site.

Which is the reason alongside telemetry I tend to favor using websites over apps.

Having said that there are apps that are considered mainstream and not malicious by the general population but can become a convenient backdoor for, say, a state actor.

Re: New speculative attacks on Apple CPUs

#298

Post by rasz »

phendrenad2 wrote: post #239

Seems like speculative execution is just fundamentally insecure. With SPECTRE/MELTDOWN mitigations, doesn't CPU performance drop below the same CPU performance with no branch prediction at all? Should we move back to CISC? Or maybe VLIW?

>speculative execution is just fundamentally insecure

I dont think its inevitable, might be caused by greed. You could have small separate sections of cache (or additional tag) dedicated to per thread speculation, but no designer is willing to sacrifice real estate to something that will be thrown away the instantly.

Re: New speculative attacks on Apple CPUs

#299

Post by bjackman »

eigenform wrote: post #147
twoodfin wrote: post #119

This introduced me to the idea of load value predictors. Is Apple the only chip designer using these in commercially released microarchitecture?

Probably not, but I don't think anyone has talked about it explicitly. Otherwise, there are known examples of related-but-less-aggressive optimizations for resolving loads early. I'm pretty sure both AMD[^1] and Intel[^2] have had predictive store-to-load forwarding. edit: Just noticed the FLOP paper also has a nice footnote about distinguishing LVP from forwarding during testing (ie. you want to drain your store que…

> I'm pretty sure both AMD[^1] and Intel[^2] have had predictive store-to-load forwarding.

IIRC this was how Spectre Variant 4 worked.

Re: New speculative attacks on Apple CPUs

#300

Post by bjackman »

alphabetting wrote: post #189

Is the statement from Apple just PR or is this not a usable exploit? "Based on our analysis, we do not believe this issue poses an immediate risk to our users." https://www.bleepingcomputer.com/news/security/new-apple-cpu...

CPU vendors always say this when an exploit is published before they mitigate.

Sometimes they mean "no we don't think it's exploitable", sometimes the charitable reading is "we don't think anyone is exploiting this and we think developing an exploit will take quite some time".

Unfortunately they never reveal exactly that they mean. This is very annoying, because when it's the former case, they're often right! Security researchers publish bullshit sometimes. But the vendors basically leave you to figure it out for yourself.

Post reply on HN