zlacker

[return to "Toward a Reasonably Secure Laptop"]
1. HugoDa+bg[view] [source] 2017-07-11 14:05:02
>>doener+(OP)
"Finally, we are going to require that Qubes-certified hardware does not have any built-in USB-connected microphones (e.g. as part of a USB-connected built-in camera) that cannot be easily physically disabled by the user, e.g. via a convenient mechanical switch. However, it should be noted that the majority of laptops on the market that we have seen satisfy this condition out of the box, because their built-in microphones are typically connected to the internal audio device, which itself is a PCIe type of device. This is important, because such PCIe audio devices are – by default – assigned to Qubes’ (trusted) dom0 and exposed through our carefully designed protocol only to select AppVMs when the user explicitly chooses to do so."

This made me download Qubes. Amazing project that seems to care.

◧◩
2. pmoria+pv[view] [source] 2017-07-11 15:53:47
>>HugoDa+bg
I personally would not trust any laptop with an internal microphone at all.

If a laptop does have an internal microphone, I just assume it is on and recording.

◧◩◪
3. raesen+Yw[view] [source] 2017-07-11 16:05:11
>>pmoria+pv
Does that mean you assume that all the firmware/devices on your laptop are compromised, or just the microphone?
◧◩◪◨
4. cyphar+9m1[view] [source] 2017-07-11 22:00:13
>>raesen+Yw
CPU firmware is likely the worst type of compromise (see Intel ME). However, the issue is that private information can be gained by listening in on conversations near a laptop or by recording what the camera sees.

Keylogging isn't good either, but if you're using a password manager and/or 2FA then it's not really as big of an issue. It is an issue for your disk encryption passphrase, but I'm hoping that in the future we might be able to remedy that through some 2FA-like system[1]. If we seal disk encryption keys inside TPMs then we have to only come up with a sane security policy (which is obviously the hard part).

Disk controllers are similarly not an issue if you have full-disk encryption (though then your RAM is the weak point because it contains the keys). There was some work in the past about encrypted RAM but I doubt that is going to be a reality soon. The real concern is that a worrying array of devices plugged into your laptop can DMA your memory (USB 3.1, PCI, etc). iommu improves this slightly but from memory there is still some kernel work necessary to make the order in which devices load secure (if you load a device that supports DMA before iommu is loaded then you don't have iommu defences).

[1]: https://www.youtube.com/watch?v=ykG8TGZcfT8 "Beyond Anti-Evil Maid"

◧◩◪◨⬒
5. dlesli+np1[view] [source] 2017-07-11 22:33:07
>>cyphar+9m1
> CPU firmware is likely the worst type of compromise (see Intel ME).

I see it, and I see the AMD and ARM equivalents, and I'm sitting here wondering how the hell do I buy a decent laptop without that crippling trust hole. AFAICT, one cannot.

I'm willing to pay more for processors that aren't thus afflicted. Is anyone at AMD, Intel et al listening?

◧◩◪◨⬒⬓
6. cyphar+NZ1[view] [source] 2017-07-12 08:07:03
>>dlesli+np1
> AFAICT, one cannot.

I believe so too. OpenPOWER and RISC-V show great promise but I am not aware of any significant tape-outs for either (and not to mention you have to have consumer motherboards et al that are compatible with the chipset).

The nice thing about OpenPOWER is that there are many distributions (openSUSE is one that I know for sure) that provide some support for ppc64le and thus the transition shouldn't be too painful from a port-the-distro perspective. RISC-V also will have similar support once it's merged into the mainline kernel and also once distributions have significant confidence to spin up some QEMU build images for RISC-V.

> I'm willing to pay more for processors that aren't thus afflicted. Is anyone at AMD, Intel et al listening?

I am inclined to believe that the reason is economic rather than them just being evil (that doesn't mean that it's not a horrible misfeature that mistreats users, I just don't think that the inclusion of ME on consumer hardware was an intentional decision). Intel ME is "required" for enterprises because sysadmins want to be able to control all of the machines they provide their employees (you can have varied opinions on whether that's ethically acceptable, but that's the reason).

Given that consumer hardware generally comes from the enterprise world after it has dropped in value, I would not be surprised if Intel ME was left in consumer CPUs simply because it was cheaper than removing it. There's also the (weaker) argument that an enterprise should be able to use Intel ME on a BYO-device system, but that strikes me as unethical.

You might be willing to pay extra for Intel ME-less CPUs, but have you seen what the bill is for a full tape-out? There needs to be significant market demand for something like that.

◧◩◪◨⬒⬓⬔
7. gcb0+vk4[view] [source] 2017-07-13 09:24:01
>>cyphar+NZ1
if it was economical they would offer you to pay more for full control for it.

but even a sysadmin at a fortune 500 company is in the dark about all that this second cpu can and can't do.

[go to top]