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

111–120 of 233 posts

Re: Apple Exclaves

#111

Post by kennysoona »

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 (VTL1). VTL1 has its own kernel, separate from the Guest kernel, referred to as the Secure Kernel.

[1] https://lssna24.sched.com/event/1aIeD/linux-virtualization-b...

Re: Apple Exclaves

#112

Post by vintagedave »

hello_computer wrote: post #100

Apple works wonders protecting their plantation, but what protects you from them? Have any of you pondered the prospect of “ the last geohot ”?

I had to google. There's a hacker called geohot, is that what this comment is referring to?

Could you explain what you mean more please?

Re: Apple Exclaves

#113

Post by lordofgibbons »

ChrisMarshallNY wrote: post #104
eleveriven wrote: post #78

Earlier quoted context omitted.

Tim definitely carries that torch in his own way, but there was something about Steve's presence that made everything feel more… human? Less corporate? Hard to put into words, but yeah, I miss him too. Thanks for sharing that video.

One of the things about Tim Cook, that people don’t really talk about (which, IMO, is appropriate), is that he’s openly gay. Most times, this doesn’t mean anything, but there’s very few demographics that understand the need for privacy and data protection, better than gay folks. 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,…

> 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 of your photos on your iPhone and implement dark patterns to trick you to upload your data to iCloud. Just 1 CEO change away from having them from being a privacy advocate to a privacy nightmare.

Re: Apple Exclaves

#114

Post by lambdaone »

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 to prevent an attack by rapidly flicking the camera logic on and off.

A similar circuit for the microphone with a different-coloured physical LED - not just a software-controlled dot on the screen - would be a good idea too.

Re: Apple Exclaves

#115

Post by auggierose »

sapphicsnail wrote: post #83
auggierose wrote: post #73

Earlier quoted context omitted.

I know very few people who would't use their wealth to try to save their lifes, or that of their loved ones. It's kind of what wealth is for.

You know that's still bad right?

If it is bad to use your money to legally buy yourself advantages that other people cannot afford to buy, then capitalism is bad.

Do you think capitalism is bad?

Re: Apple Exclaves

#117

Post by api »

We could have avoided so much hardware and OS complexity if we'd instead (mostly) discarded the idea of shipping and running compiled code directly on the hardware.

TL;DR: we are doing things in hardware that ought to be done in software, and we're giving software too close to metal access.

User mode should be something like the JVM, but more language-neutral, something based around WASM for example. The runtime for this should ideally be written in a memory safe language and very extensively tested. User mode code should not have access to raw pointers, raw CPU, etc.

If we'd done this we also could have elevated things like the common API beyond the lowest common denominator of C. We used to have a ton of research and some fielded systems like this: Smalltalk, LISP machines, the JVM, the CLR, etc. The JVM and the CLR are still quite alive and well but the HN world seems to hate them for some reason. Smalltalk and efforts like the LISP machines died out.

Re: Apple Exclaves

#118

Post by lxgr »

saagarjha wrote: post #93
lxgr wrote: post #39

Earlier quoted context omitted.

Delegating key derivation and/or password validation, combined with secure UI state indication, to a more secure execution environment can be a big win for security, for example. I could imagine a passkey implementation with some extensions that allow securely presenting what the user is consenting to and how ("enter your payments PIN or password now to confirm a payment of $x to merchant y"). It's of course even bet…

This is apparently already a thing

Which part?

Apple is already using the secure enclave for key derivation, PIN/password rate limiting etc. (that’s what it’s for), but my point is that there’s currently a gap in that you can often not really know if you are actually talking to the secure enclave or OS-level malware.

Re: Apple Exclaves

#119

Post by brookst »

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 gets complicated. “The camera” is a bunch of parts. You’d probably want to key off of the CMOS sensor power, but that has several power levels for standby, sleep, idle. So your hardware circuit would likely to know current, not just voltage. Or maybe go upstream and parse the I2C (or whatever) messages signaling power mode changes?

And then your LED driver would need to know screen brightness (or connect to the ambient light sensor) because you want to be bright enough to see in direct sunlight, but that level of brightness would be unpleasant (and maybe screw up legit camera use) in low light.

So if you believe your SK is secure, you can do a better job more simply by using it. And if you don’t think SK is secure, all bets are off anyway.

Post reply on HN