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

Apple Exclaves

randomaugustine.medium.com

Post reply on HN
Print view View original

161–170 of 233 posts

Re: Apple Exclaves

#161

Post by 0cf8612b2e1e »

supriyo-biswas wrote: post #146
lambdaone wrote: post #114

I'm quite surprised that they use a secure exclave to control the physical camera LED - this is absolutely massive overengineering to do something very simple. A tiny bit of hardwired dedicated logic integrated into the camera module would be more than adequate to do this - just gating of either the digital I/O or the power to the camera, and a pulse-stretcher so the LED goes on for at least a few seconds each time t…

> just gating of either the digital I/O or the power to the camera, and a pulse-stretcher so the LED goes on for at least a few seconds each time to prevent an attack by rapidly flicking the camera logic on and off. They'd be unable to roll out the feature to older iPhones if they did this. I guess for newer iPhones this is not as big of a deal since they have a big-ass notch anyway, however Apple also has a large cu…

What product line anywhere says, “Buy our old models, just as good as the latest!”

Re: Apple Exclaves

#162

Post by RussianCow »

rollcat wrote: post #160
Vendan wrote: post #145

Earlier quoted context omitted.

I'm a software engineer at a company that does all macbooks. I hate my M1 macbook because it's way less reliable then my desktop, both software and hardware. I have to hold the power button to force it off roughly twice a month, it absolutely refuses to play nice with my KVM (that my desktop has no issues with), and the "keyboard secure input" feature regularly goes on the fritz and breaks anything that taps into the…

> I have to hold the power button to force it off roughly twice a month [...] Hmm... $ last | grep reboot reboot time Sun Feb 16 14:10 reboot time Fri Feb 14 19:40 reboot time Thu Jan 30 09:52 reboot time Fri Dec 13 16:20 reboot time Tue Oct 29 15:32 reboot time Tue Sep 17 12:19 [...] I guess most of these are from macOS updates. I don't think I've used the power button at all in the past year or so? FWIW I'm using a…

> There's an argument that this is a trade-off vs increased IT support cost/workload, but I guess SWEs don't need much support to begin with?

IME, it's also about being able to ensure that everyone has access to the same software. I worked at a company that used macOS-specific software for development (I think it was Sketch?) so I had to have a MacBook around, even though I primarily used a Linux desktop for work. Anecdotally, I don't think this is uncommon.

Re: Apple Exclaves

#163

Post by alwayslikethis »

brookst wrote: post #121
lordofgibbons wrote: post #113

Earlier quoted context omitted.

> Of course, he’s still at the whim of the Board, and he’s no spring chicken, so there’s no guarantee that his successor would feel the same At the risk of sounding like Richard Stallman, that exactly is the problem with buying into such walled-prison ecosystem of devices. You're at the mercy of Apple pushing an update that can unilaterally take away your privacy and rights. They already do that with sending hashes o…

Sure, and every time you eat at a restaurant they could poison you. This is mainly a concern if you are a high value target likely to be the first person poisoned. For most of us, that’s not true, and a formerly good actor turning evil would be noticed long before it came our turn. So there’s the idealist “I can’t be sure my favorite restaurant won’t poison me today, so I’m never eating there again”, and the pragmati…

Your analogy doesn't really work because a food poisoning attack is hard to scale (across restaurants, locations) without being detected, whereas one backdoor can compromise everyone all at once if they all have the same software.

If Apple adds a backdoor to their E2EE (by sending their servers the key) via a software update, and they don't do anything with the secrets exposed, they can compromise a large proportion of users over just a few weeks and there is a big chance you'll be among the "first", because the "first" is now a large set.

Re: Apple Exclaves

#164

Post by cantrecallmypwd »

seL4 is awesome for its formal engineering. One of the main gotchas though with purer (less hybrid) microkernel architectures is the coordination of transactions that touch multiple services, i.e., a system call or event that touches multiple hardware areas and must execute rollback code should any one of them fail.

Re: Apple Exclaves

#165

Post by alwayslikethis »

lukifer wrote: post #136
brookst wrote: post #121

Earlier quoted context omitted.

Sure, and every time you eat at a restaurant they could poison you. This is mainly a concern if you are a high value target likely to be the first person poisoned. For most of us, that’s not true, and a formerly good actor turning evil would be noticed long before it came our turn. So there’s the idealist “I can’t be sure my favorite restaurant won’t poison me today, so I’m never eating there again”, and the pragmati…

The better analogy might be, "when the morality police call the restaurant, they divulge which table you sit at every day during lunch". And it's also not clear that it would be noticed: national security letters, gag orders, parallel construction, etc. It's just another principal-agent problem, and I agree that a fully self-sovereign life, with no dependence on trust or agents, is an unrealizable ideal; and, that a…

> a fully self-sovereign life, with no dependence on trust or agents, is an unrealizable ideal

I agree with this part, but relying Apple is quite far from self-sovereignty compared to many other practical alternatives: not relying on external clouds, GrapheneOS, Linux. By relying on Apple, you not only pay a tax to essentially bribe them to not attack you (perhaps a viable strategy, not too different from taxes to governments), but more importantly you give up the ability to resist without serious compromises (can't have E2EE backups on your own cloud if they said so). This is akin to trying to be paying taxes to the government to get better police coverage, and they decide to ban locks, security cameras, and leaving the walled garden.

The problem with the current computing security paradigm is that it puts too much trust in entities that do not deserve it, because the entities are simply too powerful and do not suffer consequences when they break that trust.

Re: Apple Exclaves

#166

Post by saagarjha »

kennysoona wrote: post #111

I wonder how this compares to Linux Virtualization based Security? From the page[1] with the video: a security feature that can a) harden the kernel and b) ensure that critical kernel resources remain untampered, even if the kernel gets compromised. VBS uses hardware virtualization and the hypervisor (Hyper-V) to create an isolated virtual environment that runs as a higher trust level, called Virtual Trust Level 1 (V…

Exclaves run at a parallel trust level.

Re: Apple Exclaves

#167

Post by lern_too_spel »

nedt wrote: post #156
lern_too_spel wrote: post #22

Earlier quoted context omitted.

Steve believed at his core that locking down devices was the best way to extract business value from users. That's why you can't install any apps without telling Apple or get your location without sending it to Apple. He also believed very strongly in good marketing, and he jumped on privacy marketing very quickly after the Facebook - Google privacy spat that coincided with the failure of iTunes Ping.

The first iPhone didn't have an app store and the idea was to just use websites and later install webapps. On that there is no control whatsoever, so no I don't think the original idea was to lock down the devices for business value.

The two examples I gave are where locking a device down to extract value from customers conflict with privacy for those same customers. The former won years ago, and there has been no change since.

The iPhone had to add an app store because there were some apps that users couldn't build on the web at the time. They since allowed apps, but those apps are restricted to a proper subset of the APIs that first party apps get.

Re: Apple Exclaves

#170

Post by lambdaone »

runjake wrote: post #154
lambdaone wrote: post #114

I'm quite surprised that they use a secure exclave to control the physical camera LED - this is absolutely massive overengineering to do something very simple. A tiny bit of hardwired dedicated logic integrated into the camera module would be more than adequate to do this - just gating of either the digital I/O or the power to the camera, and a pulse-stretcher so the LED goes on for at least a few seconds each time t…

It’s not over engineering. It’s because of research like this, along with other researchers like Charlie Miller. Apple generally isn’t out to make things willfully overcomplicated without good reason. https://news.ycombinator.com/item?id=42260379

All of which is fantastic, until you can't trust Apple because they are under a secret obligation to disable that feature. Non-programmable hardware gating the I/O lines or power isn't hackable in the same way.
Post reply on HN