[nicebill8]

> All Mac portables with the Apple T2 Security Chip feature a hardware disconnect that ensures the microphone is disabled whenever the lid is closed.

vs.

> On the 13-inch MacBook Pro and MacBook Air computers with the T2 chip, and on the 15-inch MacBook Pro portables from 2019 or later, this disconnect is implemented in hardware alone.

Do these statements not contradict each other for the 15" 2018 MacBook Pro, for example, which includes a T2 chip? This would also contradict earlier documentation provided on the T2 chip by Apple themselves [1].

From [1]:

> All Mac portables with the Apple T2 Security Chip feature a hardware disconnect that ensures that the microphone is disabled whenever the lid is closed. This disconnect is implemented in hardware alone, and therefore prevents any software, even with root or kernel privileges in macOS, and even the software on the T2 chip, from engaging the microphone when the lid is closed.

[1] https://www.apple.com/euro/mac/shared/docs/Apple_T2_Security... (October 2018, page 13)

[alias_neo]

I don't think they contradict each other. The way I read it is, the former, have hardware disconnects controlled by some software/firmware, such as a relay/MOSFET or something of that kind; an electronic switch.

The latter I read as being hardware _only_; "only" being the key addition to this sentence. I would expect this implementation to be something like a reed switch to magnetically disconnect the lines _physically_ rather than electronically.

[ken]

Isn't the whole point of software to control hardware, at some level? How is hardware-controlled-by-software different from plain old software-controlled? If a switch can be closed by software, I'm having trouble putting my finger on exactly what security benefit that might offer.

[derefr]

> How is hardware-controlled-by-software different from plain old software-controlled?

Perhaps it’s that the hardware interlock on the microphone can be enabled by software, but can only be disabled by a physical action (i.e. opening the lid.)

[jaywalk]

The security benefit here is that software has no access to this hardware switch.

[hamiltonkibbe]

I don't think the distinction is a FET vs a reed switch -- the means of blocking electrons, rather, it's in what decides whether that switch is open or closed. I would consider a circuit like this driving the FET/relay/etc. to be a "hardware disconnect" (using HDL to describe the circuit, not suggesting it should be programmable logic):

  module mic_enable (lid_closed, lots, of, signals, mic_enable);
    input lid_closed, lots, of, signals;
    output mic_enable;
    assign mic_enable = !lid_closed & lots & of & other & signals;
  endmodule

[simias]

I think that there are two aspects to this problem of hardware disconnects: can we really sure that the disconnect actually cuts the microphone and then can we be sure that this disconnect is driven reliably to cut the mic when we want it to be cut.

Having a separate FET/reed switch is about the former: having a discrete component makes it easier to audit and make sure that the microphone is indeed cut off. Technically messing with the audio codec config or pin muxing is probably equally as efficient when it comes to muting the audio input, but that's a lot more difficult to audit.

But then all all that is pointless if the code driving the switch is broken or has a backdoor. Given that most people won't disassemble their phone or laptop to put a probe on the FET/reed/whatever driving signal I feel like this is just a marketing smoke screen.

If I have to trust Apple's firmware to drive the "hardware" switch reliably, why not make things simple and trust Apple's OS to mute the audio codec reliably?

[hamiltonkibbe]

I think the whole point is that there is no code (firmware or otherwise) driving the switch. I guess it depends on your threat model, but if you don't trust apple's hardware or firmware to disconnect the microphone, you can't trust their hardware not to have another microphone somewhere else that isn't advertised and is on all the time.

I'd take the term "hardware disconnect" in this sense to mean that there exists no program that you can run on any of the processors, or no bitstream you could load into any FPGA on the device that would be able to enable the microphone when it shouldn't be enabled, eliminating the threat of malicious code enabling the microphone