
Toward a Reasonably Secure Laptop - doener
https://www.qubes-os.org/news/2017/07/08/toward-a-reasonably-secure-laptop/
======
HugoDaniel
"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.

~~~
pmoriarty
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.

~~~
raesene6
Does that mean you assume that all the firmware/devices on your laptop are
compromised, or just the microphone?

~~~
cyphar
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](https://www.youtube.com/watch?v=ykG8TGZcfT8)
"Beyond Anti-Evil Maid"

~~~
dleslie
> 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?

~~~
cyphar
> 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.

~~~
gcb0
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.

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

The sysadmin might not know how it works, but they do know they can control
machines remotely using their Intel branded management system (or other
rebranded variety). Just because they don't know how bad it is doesn't mean
that's not the motivation for it.

IPMI is a similar deal. Modern servers have a secondary computer embedded in
the motherboard (which have been historically _very_ insecure) because it's
useful for managing servers. Intel AMT is the work-laptop version of that
technology, and you can bet that most enterprises use it.

> if it was economical they would offer you to pay more for full control for
> it.

But they do. The entire reason why enterprise deployments of large numbers of
work laptops/desktops is so expensive is because you have to pay extra for the
management system that comes with it. Just because they don't remove the
"backdoor" in their consumer lines doesn't mean they won't charge you through
the nose to be able to administer the damn thing.

I am very anti-ME and wish that all firmware was free software, but arguing
that the reason why ME is present in consumer CPUs is not for economic reasons
doesn't sound right to me. The reason why the technology was developed is
because the developers were not aware how unethical their actions were, and
that's where the core of this problem lies.

------
x86insecure
There are things we can do to help get us out of this Intel ME rut.

* Let AMD know that open-sourcing/disabling PSP is important to you [1].

* Contribute to RISC-V. You can buy a RISC-V SoC today [2]. Does your favorite compiler have a RISC-V backend?

[1]
[https://www.reddit.com/r/linux/comments/5xvn4i/update_corebo...](https://www.reddit.com/r/linux/comments/5xvn4i/update_corebootlibreboot_on_amd_has_ceo_level/)
[2]
[https://www.sifive.com/products/hifive1/](https://www.sifive.com/products/hifive1/)

~~~
AdmiralAsshat
AMD is not going to open-source or disable PSP. That thread was _four months
ago_ and they still haven't even commented publicly on it. See this recent
update from 8 days ago:

[https://www.reddit.com/r/Amd/comments/6krg13/has_there_been_...](https://www.reddit.com/r/Amd/comments/6krg13/has_there_been_any_development_on_the_possibility/djoo6cg/)

If AMD really wanted to, they would have announced something by now. I can
commend the AMD rep who continues to push for it, but he can't dictate company
policy.

~~~
problems
Yeah, given Intel's support for TXT and SGX which are basically moves in the
opposite direction, I highly doubt they want to lose customers over things
like not being able to play some new DRM'd content from Netflix. The gain from
this is probably minimal compared to the loss from something like that. While
I'd definitely buy it, the market potential of it seems limited overall.

Though it's possible they could just offer it as an option on some chips to
get both markets which would do the job, but given the sheer diversity of ARM
and possibly RISC V SoC vendors, those might be a better starting place than
x86.

------
cyphar
> Another important requirement we’re introducing today is that Qubes-
> certified hardware should run only open-source boot firmware (aka “the
> BIOS”), such as coreboot.

I recently flashed coreboot on my X220 (and it worked surprisingly enough).
However, I couldn't find any solid guides on how to set up TianoCore (UEFI) as
a payload -- does Qubes require Trusted Boot to be supported on their
platforms (I would hope so)? And if so, is there any documentation on how to
set up TianoCore as a payload (the documentation is _sparse_ at best, with
weird references to VBOOT2 and U-Boot)?

Otherwise I'm not sure how a vendor could fulfill both sets of requirements.

------
d33
If I read that right, they're allowing Intel ME, which sounds like a sad
compromise to me. Given that it's a pretty big complex black box that one
can't easily disable, would you agree that x86 is doomed when it comes to
security? If that's the case, is there any hope we could have a CPU with
competitive capabilities? (For example, is there an i7 alternative for ARM?)

What could one do to make it possible to have ME-less x86 in the future?

~~~
vbezhenar
When you're running megabytes of proprietary code on numerous processors in
your laptop completely out of your control, why do you focusing on Intel ME?
What about your network card which runs dedicated processor with some kind of
operating system, executing firmware and processing every network frame before
your OS receives it, for example?

~~~
majewsky
When the network card tampers with the packets, this can be detected if the
network protocols use the correct cryptographic algorithms to ensure integrity
and confidentiality. Protecting against tampering on the CPU level is much
harder, since this is where these algorithms are carried out.

~~~
problems
If you think you're going to catch every possible NIC-level modification, does
tampering on the CPU really matter if there's no way to store or exfiltrate
the data without being detected?

------
Taek
Is this something we could achieve with a corporate alliance? I know a lot of
tech companies would like to give their employees secure laptops. I also know
that there are large costs associated with making hardware, especially if you
are talking about dropping ME.

A dozen companies with 1000 employees each and a budget of $2,500 per employee
gets you $30 million, which is surely enough to get a decent, qubes-secure
laptop with no ME. You aren't going to be designing your own chips at that
point, but you could grab power8 or sparc or arm.

Are there companies that would reasonably be willing to throw in a few million
to fund a secure laptop? I imagine at least a few. And maybe we could get a
Google or someone to put in $10m plus.

~~~
Xeoncross
I would think that one company (Google, Amazon, Facebook, etc..) that cared
enough would be better off SOLEY funding a project like this for themselves
first - then others second.

$100 Million investment isn't a stretch for something from a large company.

~~~
brians
They did. Apple laptops have no ME, and Chromebooks are safe (e.g., the source
is open to Google!)

~~~
cyphar
ChromiumOS is what Google bases ChromeOS on, and it's source is available
(most notably, the U-Boot and device-specific firmware source is available for
all Chromebooks). That's one of the reasons why Chromebooks are so well-
supported by coreboot.

~~~
gcb0
very wrong.

from their site:

"For years, coreboot has been struggling against Intel. Intel has been shown
to be extremely uncooperative in general. Many coreboot developers, and
companies, have tried to get Intel to cooperate; namely, releasing source code
for the firmware components. Even Google, which sells millions of chromebooks
(coreboot preinstalled) have been unable to persuade them.

...

Basically, all Intel hardware from year 2010 and beyond will never be
supported by libreboot...."

------
ashleysmithgpu
Looks like Qubes make you pay to get certified:
[https://puri.sm/posts/](https://puri.sm/posts/) "The costs involved,
requiring a supplementary technical consulting contract with Qubes/ITL (as per
their new Commercial Hardware Goals proposal document), are not financially
justifiable for us."

~~~
AdmiralAsshat
That's a little disappointing. I understand there's financial costs involved
in someone certifying the thing, and I understand that consultant should be
paid for their work, but for the sake of having a "flagship" laptop that
QubesOS can point to--in addition to the fact that the OS would likely gain
greater adoption from being a pre-installed option on a laptop--you would
think that Qubes might be willing to eat the cost.

~~~
lmm
In principle I'd agree, but I don't get the sense that Qubes is exactly flush
with cash.

------
Aissen
> The vendor will also have to be willing to “freeze” the configuration of the
> laptop for at least one year.

This is one of the most important points. The speed at which laptop vendors
are releasing new SKUs is staggering. I know the whole supply chain is to
blame, but apart from a few models, the number of different SKUs is way too
high.

~~~
digi_owl
Simply put, they are trying to hit every gap in the market because their
products are what economists like to call fungible. There is simply not enough
to distinguish between them.

This is why Apple can sit with just a few models year after year, because they
are the sole vendor of OSX/MacOS.

------
notacissp
This article helped me get up and running with Qubes:

[https://medium.com/@securitystreak/living-with-qubes-
os-r3-2...](https://medium.com/@securitystreak/living-with-qubes-
os-r3-2-rc3-for-a-week-1a37e04c799e)

------
digi_owl
Once more i get the impression that computer security people are off in a
different universe where a computer at the bottom of the ocean is a
"reasonable" way to do computing.

~~~
watersb
A computer at the bottom of the ocean is not to be trusted, unless you are
willing to stay on-site and verify it yourself.

------
listic
Looks like even Purism is not interested in certifying compatibility with
Qubes anymore. That's sad.

------
awinter-py
It's a shame that chromebook's boot verification isn't easily extensible to
open source.

