Installer refuses to have /boot mount point on encrypted boot device (libreboot permits that)

[Thierry Laurion]

Hi,

I've flashed libreboot over a p8700 x200 thinkpad (I suspect required microcode updates for vt-x and vt-d are there even if AMT and ME are disabled.
That would make the perfect laptop!!) and tried to install Qubes over luks fully encrypted disk following this procedure:
http://libreboot.org/docs/gnulinux/encrypted_parabola.html

But it failed saying it needed a bios_grub partition, for which I followed this procedure:
https://github.com/voidlinux/documentation/wiki/Installer-Partitioning

Qubes installer complained when ready to install that:
/boot cannot be of type lvmlv
/boot cannot be on an encrypted block device

It should be possible to install everything under luks, considering that libreboot can manage the luksOpen and cryptsetup directly from it's grub payload, not exposing /boot content which was the weakest link and needed signed kernel and initrd.

How can we invalidate that check in the installer?

Regards,
Thierry

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

In most cases, having /boot on LUKS volume would make the system
unbootable, installer shouldn't allow that. The proper way would be to
first check if the system will be able to use such configuration.
Unfortunately we can't do that without a hardware to test it (which BTW
we might have in the near future, hopefully).
So for now, your option is to install system with unencrypted /boot and
only then move it to encrypted volume (and wipe the original /boot). If
you don't want to have some unused partition left on your disk, you can
use for example USB stick for that temporary /boot.

If you know how to reliably detect whether the system support encrypted
/boot (without unencrypted stage1 in the MBR/ESP...), let us know, so we
can add such check to lift the unencrypted /boot requirement then.
Or even better - provide it as a patch for installer-qubes-os repository
:)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWNOQsAAoJENuP0xzK19csNeEH/0wGid54O67tjb/ZMS2D4r+u
4ZhBzIEVbjuaZ7CiLa3gp+Nmt13LUztBrxjQrRdJD1dPxTX1cy/LS617OEUti995
Wx6dbxu/sH3rg891yfRr0AcsHd7E0flv1cy1n5G+w/ixxqV9qcRbzg8bvUzlkpB5
3hF30CrSj6ZWEYrFaMscmANVcrzX0AkwchMXRwRW7wq/SKDqs0i30N9eA+wP3a6P
wDh4+WpGhTMYX3PN5/QpKwTOviKeU1q+0h1fehdBrI9JdBS3PY8xk3ahvPtuMTBr
PMZkgAYGE2OUWO8FCp8RpRXXezsvmPoB1u++lPzZYnt7onqaoTZNMm4jZKisJh0=
=yXY7
-----END PGP SIGNATURE-----

[Thierry Laurion]

If bios is coreboot or libreboot,  system can definitively boot from encrypted boot device :)

[Thierry Laurion]

Through dmidecode?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Jan 22, 2016 at 11:50:01PM -0800, Thierry Laurion wrote:
> Through dmidecode?

Can you provide sample output from libreboot based system?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQEcBAEBCAAGBQJWo6rKAAoJENuP0xzK19csNTkH/2MNjvwQrSa1Lq7kHt3Dmjaz
lCNnV9S6GzxJtnBDZLww/W7+wXZQr2bsJW+pUdEF7iJ1hKqXKV5Ocj/LE6HegR7s
WfpWEpUdxXEPCQDjpMo6XR9IrilEJkoeIoV/r/7ldEgw0EMbeei2HT2Fd3WjIBTs
Cd9I0AmqR8EYvzZ3xsZaz51cpFE+wEoNChwTUdOdRmoqKY5NNrn4b9cQkPaCEYXV
TX+yQCIWejEb+q+xGbnuhMdkaJhPLBz9kMk9jft7nRRLHeEMqS+X1+bnU0nGw/zN
140s/1JapZg/tTIHI1t8YQ4hjmZBufDg52wXq37zKIBySiCKhp78h/keKso8HUQ=
=WHfV
-----END PGP SIGNATURE-----

[Thierry Laurion]

Le samedi 23 janvier 2016 11:31:14 UTC-5, Marek Marczykowski-Górecki a écrit :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Jan 22, 2016 at 11:50:01PM -0800, Thierry Laurion wrote:
> Through dmidecode?

Can you provide sample output from libreboot based system?  

Coreboot users could all profit of anti-tempering through grub payload usage.

On dom0:
sudo dmidecode -s bios-vendor
coreboot

Where would that be checked, so that the partition scheme is not refused?

Regards,
Thierry

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Mar 27, 2016 at 08:00:36PM -0700, Thierry Laurion wrote:
>
>
> Le samedi 23 janvier 2016 11:31:14 UTC-5, Marek Marczykowski-Górecki a
> écrit :
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On Fri, Jan 22, 2016 at 11:50:01PM -0800, Thierry Laurion wrote:
> > > Through dmidecode?
> >
> > Can you provide sample output from libreboot based system?
> >
>
> Coreboot users could all profit of anti-tempering through grub payload
> usage.
>
> On dom0:
> sudo dmidecode -s bios-vendor
> coreboot
>
> Where would that be checked, so that the partition scheme is not refused?

Currently default partition requirements are set here:
https://github.com/QubesOS/qubes-installer-qubes-os/blob/master/anaconda/pyanaconda/installclasses/qubes.py#L58-L66

This uses blivet library:
https://github.com/rhinstaller/blivet/blob/master/blivet/platform.py

There may be additional place, where (possibly manually modified)
configuration is verified against requirements. Check here:
https://github.com/QubesOS/qubes-installer-qubes-os/blob/master/anaconda/pyanaconda/bootloader.py

Anyway probably the easiest way would be to adjust the requirements in
installlclasses/qubes.py. And then adjust appropriate Bootloader class
to really use gtub coreboot payload.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW+PTaAAoJENuP0xzK19csvVYH/3XKZjWt/NBLbbsUFCWhcsEr
AU0t+M7QhcQD9wZ4LJ2Jix7ml2iPmBjEpJjhe8TXbJT2+Xw8ju85QPJFDn5rdmO+
qylcynMam+7XyMKp+VFBKj0UPSkc0aS0tT9xkNkxecbkmwLHJsKp+YUhmD5yKwtb
AS2Pdcre3cmremo5TOzOOlSC6dWx5FXTIxyChRzNHbs8Y0aP0FLqfhG3Blt9XDjP
eqYbBeJB91jwl1v8+N+K/24G2mo8JcuhWXpT9uZVTTG88zZ0ZZBYHTvtK5NG0CZD
4eI6G1E9qeyF9+64TEpulm0SP9703Ncyaaq/2aMrgtJ03pn/7edNE22hT0u9KBg=
=tx47
-----END PGP SIGNATURE-----

[Thierry Laurion]

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-devel/044FDrqJDPc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-devel...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20160328090945.GJ1726%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Hey, cannot test my diff right now, but I was thinking that it would do the job.



Thierry

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Hey, cannot test my diff right now, but I was thinking that it would do the
> job.
>
> Thierry

> --- bootloader.py.orig 2016-03-28 20:29:17.348000000 -0400
> +++ bootloader.py 2016-03-28 20:36:16.772000000 -0400
> @@ -40,6 +40,7 @@
> from pyanaconda.nm import nm_device_hwaddress
> from blivet import platform
> from pyanaconda.i18n import _, N_
> +import subprocess
>
> import logging
> log = logging.getLogger("anaconda")
> @@ -224,6 +225,8 @@
> image_label_attr = "label"
>
> encryption_support = False
> + if subprocess.check_output(['dmidecode', '-s', 'bios-vendor']) == "coreboot\n" :
> + encryption_support = True

Not sure if class definition time is the best time to do that. Better in
__init__.

Is it enough to know if coreboot have grub payload (not seabios or sth
else)? Or all coreboot users are clever enough to know what to do? ;)

How is grub configured to know which device use to load its config, then
xen/kernel/initrd? Shouldn't that also be done somewhere here?

> stage2_is_valid_stage1 = False

>


- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW+dQXAAoJENuP0xzK19csX4kIAJcI3s5Rfa3oAHNsluGIOr5u
xZF8Gv0uF2ToCVqR5CRSaJ2LpRd12mYDDDUa/q5CQGQIuPJg9v/CvTIr6yCe+HQ7
cBRUUvJkl4+Ib+F9r4RjybUZbiwPxWLNcxKC8IHibm6NzQcPDugvejpFvkPwEq46
3QOoam/CSJQTSZw1Gcjaw4llGXN/3M/NG9Ks72op1gO8YaQXwtT9+KsXiYRdlVh/
nzkgog3p67MO1OUB2HUXErtuNALQeD5ixNXgYw0fOllOxC/t/6EJOG+k/ZK9Da3q
/pV1U0T/HyCJUPNb7/lXaz9wa3LpmypDdbQ9arYTTFgJs3kmoXJXvV6ajKC9Da0=
=drtD
-----END PGP SIGNATURE-----

[Thierry Laurion]

I do not think there is any more specific way of checking for libreboot, or coteboot with grub payload more specifically, from within the OS.

How is grub configured to know which device use to load its config, then
xen/kernel/initrd? Shouldn't that also be done somewhere here?

The actual grub configurarion from within luks needs to be generated as if nothing changed from the boot perspective. It will be searched after luks volume is opened from within by the grub payload.

See here:

https://libreboot.org/gitweb/?p=libreboot.git;a=blob;f=resources/grub/config/menuentries/common.cfg;hb=HEAD

With file autocompletion magic, that file could also be patched to search for something more general then "matrix" lvm volume names it currently looks for.

Regards,

Thierry

[Thierry Laurion]

Hi all,

The attached diff contains all the required functional changes (unsexy) to bypass anaconda requirements in having unencrypted boot partition outside of a luks container so that coreboot/libreboot GRUB2 payload can search that container and load grub.cfg from there.

I would need help to understand what else needs to be changed so that the internal initrd and dracut scripts don't include modifications to try to open the luks container itself from within the initrd, since it was already opened externally from the libreboot/coreboot.

Previous status:

-boot partition needed to be unencrypted, contained kernel and initrd to decrypt luks container and continue from there.

Actual scenario:

-libreboot/coreboot opens luks container, finds grub.cfg and loads it in root partition

-actual initrd also runs luks open script (undesired)

-Everything works but container needs to be opened twice

Desired scenario

-libreboot open luks container and search grub.cfg within

-grub2 multiboot magic works without calling luks container open scripts

-system boots normally

Any hint would greatly be appreciated in disabling luks opening scripts from within anaconda scripts.

X200/t400 and others will never contain vt-d2 (interrupt remapping) that Qubes requires for maximal coompartimentalization. But libreboot enabled laptops will permit to control boot sequence and filesystem tempering, while sucessfully disabling AMT and ME, which Purism 13 will never permit. New is not always better :)

Thierry

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Apr 10, 2016 at 04:57:41PM +0000, Thierry Laurion wrote:
> Le lun. 28 mars 2016 à 22:13, Thierry Laurion <thierry...@gmail.com> a

Linux kernel somehow must obtain disk encryption key. It can be handed
over from libreboot (not sure how), or simply embedded into initramfs
(keyfile) as initramfs itself will be on encrypted partition. The later
should be simpler, I would look into rd.luks.key option (man
dracut.cmdline).

> Previous status:
> -boot partition needed to be unencrypted, contained kernel and initrd to
> decrypt luks container and continue from there.
>
> Actual scenario:
> -libreboot/coreboot opens luks container, finds grub.cfg and loads it in
> root partition
> -actual initrd also runs luks open script (undesired)
> -Everything works but container needs to be opened twice
>
> Desired scenario
> -libreboot open luks container and search grub.cfg within
> -grub2 multiboot magic works without calling luks container open scripts
> -system boots normally
>
> Any hint would greatly be appreciated in disabling luks opening scripts
> from within anaconda scripts.
>
> X200/t400 and others will never contain vt-d2 (interrupt remapping) that
> Qubes requires for maximal coompartimentalization. But libreboot enabled
> laptops will permit to control boot sequence and filesystem tempering,
> while sucessfully disabling AMT and ME, which Purism 13 will never permit.
> New is not always better :)

Interrupt remapping makes VT-d isolation much more effective (there are
known attacks on VT-d without interrupt remapping). So this is a
trade-off between:
- potentially malicious ME (most likely under exclusive control of
Intel and US GOV), but much stronger VT-d (rather easy to compromise
NetVM isolation)
- disabled ME, but weaker VT-d

While none of above is ideal, I still think for most threat models the
first option will be better...

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXCrJhAAoJENuP0xzK19csNdQIAJSqqdCWdzmC0jUAmX2WqSK5
hKYdxzWyhkNF6q21xbkdE5r7I10c9CVdubpAfU+24Howk8SZHol0whQt8BAM9+gc
G2PGaV3ijzUfxntvy0uS9QLGQG+hRCZ75f2ZP81QHxDuRJWKdmHoTdAu9JTOVGPJ
ZGTggoleuQQ/hYv0UhShk+0Ae3fWtrkKcvNta6wjmjY6khA7RKgT62n7Li9jAa/w
fHTFqt+aczQ9kbICj0txSsf12x/BhML5jB2XBfYaMaNcNPes16mi5cjviupV4kqs
32nF6gE2sRklURuQVMqUWDtBrG+s7sl8THL4gaX20Q3678PDKX3cEKUiDzu4yIM=
=LY+h
-----END PGP SIGNATURE-----

[Thierry Laurion]

The passphrase is obtained by grub2 from the keyboard and unlocks the luk container from within libreboot/coreboot's GRUB2, reveiling the lvms inside. From my understanding, the kernel needs to know the underlying filesystem types, but doesn't need to know the existence of the container, since it refers to root already as being a lvm.

See here:
https://wiki.parabola.nu/Installing_Parabola_on_Libreboot_with_full_disk_encryption_%28including_/boot%29#Booting_from_GRUB

I'm downloading parabola and will test this procedure. Luks container configuration and partition scheme is exactly the one being reported in the above article.

 You forget tamper proof boot sequence provided by fully encrypted disk. As a result, the trade off would be:

-Potentially malicious ME, stronger VT-d, /boot device exposed and quickly modifiable from the outside/from a usb bootable device (Anti evil maid can advise of tampering at best)

-Disabled ME, weaker VT-d (no interrupt remapping), Fully encrypted disk with tamper proof booting sequence (/boot is trustable)

While none of above is ideal, I still think for most threat models the
first option will be better... 

Any other papers/discussion threads to read to be at the same page other then the ones referereed below?
http://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
http://xen.1045712.n5.nabble.com/Xen-security-advisory-CVE-2011-1898-VT-d-PCI-passthrough-MSI-td4390298.html

Probably this discussion should be in another thread, but I would be curious if you had any quick links at hand to provide.

Thierry

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Apr 10, 2016 at 11:46:36PM +0000, Thierry Laurion wrote:
> Le dim. 10 avr. 2016 à 16:07, Marek Marczykowski-Górecki <
> marm...@invisiblethingslab.com> a écrit :

> > On Sun, Apr 10, 2016 at 04:57:41PM +0000, Thierry Laurion wrote:
> > > Le lun. 28 mars 2016 à 22:13, Thierry Laurion <thierry...@gmail.com>
> > a
> > > écrit :
> > > > Le lun. 28 mars 2016 21:02, Marek Marczykowski-Górecki <
> > > > marm...@invisiblethingslab.com> a écrit :

> > > The attached diff contains all the required functional changes (unsexy)
> > to
> > > bypass anaconda requirements in having unencrypted boot partition outside
> > > of a luks container so that coreboot/libreboot GRUB2 payload can search
> > > that container and load grub.cfg from there.
> > >
> > > I would need help to understand what else needs to be changed so that the
> > > internal initrd and dracut scripts don't include modifications to try to
> > > open the luks container itself from within the initrd, since it was
> > already
> > > opened externally from the libreboot/coreboot.
> >
> > Linux kernel somehow must obtain disk encryption key. It can be handed
> > over from libreboot (not sure how), or simply embedded into initramfs
> > (keyfile) as initramfs itself will be on encrypted partition. The later
> > should be simpler, I would look into rd.luks.key option (man
> > dracut.cmdline).
> >
> The passphrase is obtained by grub2 from the keyboard and unlocks the luk
> container from within libreboot/coreboot's GRUB2, reveiling the lvms
> inside. From my understanding, the kernel needs to know the underlying
> filesystem types, but doesn't need to know the existence of the container,
> since it refers to root already as being a lvm.

But if the blocks on the disk are encrypted, kernel needs to know how to
decrypt them. Grub2 doesn't play any role as soon as kernel is loaded,
so it can't help there.

> See here:
> https://wiki.parabola.nu/Installing_Parabola_on_Libreboot_with_full_disk_encryption_%28including_/boot%29#Booting_from_GRUB
>
> I'm downloading parabola and will test this procedure. Luks container
> configuration and partition scheme is exactly the one being reported in the
> above article.

It looks like it prompt for the passphrase the second time:
https://wiki.parabola.nu/Mkinitcpio#Using_encrypted_root
"Using LUKS volumes

If you use LUKS for hard disk encryption, the init script will detect
the encryption automatically if the encrypt hook is enabled. It will
then ask for a passphrase and try to unlock the volume.
"

https://wiki.parabola.nu/Installing_Parabola_on_Libreboot_with_full_disk_encryption_%28including_/boot%29
"HOOKS="base udev autodetect modconf block keyboard keymap consolefont
encrypt lvm2 filesystems fsck shutdown"

Explanation: keymap adds to initramfs the keymap that you specified in
/etc/vconsole.conf; consolefont the font specified in
/etc/vconsole.conf; encrypt to unlock your LUKS encrypted disks at boot
time;"

So, for me it looks like "encrypt" hook simply prompt for the
passphrase.

But of course there may be some clever trick (for example one of those
pointed out before). I can't find "encrypt" hook in the repository, so
can't verity that.

Ok, found which one:
https://wiki.parabola.nu/Installing_Parabola_on_Libreboot_with_full_disk_encryption_%28including_/boot%29#Bonus:_Using_a_key_file_to_unlock_.2Fboot.2F
"By default, you will have to enter your LUKS passphrase twice; once in
GRUB, and once when booting the kernel.
(...)
A workaround is to put a keyfile inside initramfs, with instructions for
the kernel to use it when booting."

I doubt its being really tamper proof, a lot of things can go wrong there.
Generally all kind of Evil Maid attacks. Some example ideas:
- a second /boot (even unencrypted), which will mimic the original one
to intercept disk passphrase (probably already available somewhere in
RAM)
- https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-019-2015.txt

Having coreboot+grub2 may make EM style attacks harder, but I
wouldn't assume (without some deep analysis) it would be much harder.
In worst case it would require reflashing coreboot payload. Even when
password grub2 is password protected and doesn't allow booting from USB,
you can swap the drive to very similar one (with encrypted system) and
boot that. Or simply use SPI flasher.
Surely it rises the bar, but using AEM does it too.

> > While none of above is ideal, I still think for most threat models the
> > first option will be better...
> >
> Any other papers/discussion threads to read to be at the same page other
> then the ones referereed below?
> http://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
> http://xen.1045712.n5.nabble.com/Xen-security-advisory-CVE-2011-1898-VT-d-PCI-passthrough-MSI-td4390298.html
> Probably this discussion should be in another thread, but I would be
> curious if you had any quick links at hand to provide.

Just those two.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXCv1yAAoJENuP0xzK19csezoH/3usLyPdI7lXhkm2+FrsrAwS
CyZ/BPiPGVpaIFalmGPDxu74YAIsjf9cQTO7aVrFWLkVxP2bUE412Tvi2VtUk0hK
4N8129/D4d31pM9gdi66vpE8NDcpUWkj44YLVIclzjxe0ZfAKG11j2c51T4ieDhj
YpA4PsM/W12ZQJumVMQ/mYGbCO63c3HEhlsm55VsGpyEonL2WuqaESdj6POFrWbj
BrlpuJWHVUcnktwEsh/xQbNrI+YpeWjqqn53F/Yfv85jQ1BxHPM2SlTmulpged8m
2Eya5nsIQ9xhlm0tf47ta+yt5+RBNAzIQILqhS18eOLgN/HFi/w1Bf66ZlrAZhc=
=dxl0
-----END PGP SIGNATURE-----

[Thierry Laurion]

Parabola and Qubes behavior is to ask for password a second time when booting the kernel, as you explained. That hook can effectively point to a keyfile that does the trick, as explained in the howto you pointed at. So the bootloader.py.gitdiff patch can, as a result, be considered functionally valid as provided in the previous post. Would you change something for it to be more aesthetic and merged?

Libreboot, as a coreboot distribution, can be instructed to have the firmware to be write protected from the OS perpsective. An SPI flasher would then be needed to flash updates, which requires physical tempering of the device. The boot process can be password protected from within coreboot's grub2. As you point out, physical security is still required. Never leave your device alone, but if you do, It is possible to see if someone tempered with it.
 
Not to forget that the x200 laptop also has a recognised TPM device (that gets deactivated by libreboot not initializing DMAR tables correctly at the time of writing this, which also disables vt-d).

I have not tested Anti Evil maid myself yet, But I suppose the combination of both those technologies would be possible and may be also desirable.

Note that if such GRUB2 boot from coreboot is password protected and requires a passphrase to open the luks container before booting loading the initrd and boot the kernel with a keyfile, I do not see how it would be possible to put another disk and boot from it without knowing the passhprase to build such a replacement disk.

As you said, deciding what is worst between computrace/intel me or the absence of vt-d2 (interrupt remapping) in an interesting and difficult choice to make in the probable attack vectors used against oneself. You know any researchers interested in those particular practical questions?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Apr 13, 2016 at 02:01:16AM +0000, Thierry Laurion wrote:
> Le dim. 10 avr. 2016 à 21:27, Marek Marczykowski-Górecki <
> marm...@invisiblethingslab.com> a écrit :

There are still problems with it, similar to pointed before - generally
do not make calls at class definition level. Anyway I can take care of
it (after merging Fedora 23 dom0 support, to not do that work twice).

> <https://libreboot.org/docs/hcl/index.html> An SPI flasher would then be

> needed to flash updates, which requires physical tempering of the device.
> The boot process can be password protected from within coreboot

> <https://libreboot.org/faq/#bootpassword>'s grub2. As you point out,

> physical security is still required. Never leave your device alone, but if
> you do, It is possible to see if someone tempered with it.

> <http://lifehacker.com/use-glitter-nail-polish-to-make-your-laptop-tamper-proo-1493599646>

>
> Not to forget that the x200 laptop also has a recognised TPM device (that
> gets deactivated by libreboot not initializing DMAR tables correctly at the
> time of writing this, which also disables vt-d

> <https://www.qubes-os.org/doc/user-faq/#can-i-install-qubes-on-a-system-without-vt-d>).

>
>
> I have not tested Anti Evil maid myself yet, But I suppose the combination
> of both those technologies would be possible and may be also desirable.

Without TPM, AEM will not work...

> Note that if such GRUB2 boot from coreboot is password protected and
> requires a passphrase to open the luks container before booting loading the
> initrd and boot the kernel with a keyfile, I do not see how it would be
> possible to put another disk and boot from it without knowing the
> passhprase to build such a replacement disk.

Take a look at linked QSB19 - it is possible to prepare LUKS header for
unencrypted data, that will accept any password (and the password will
most likely still live in RAM, so malicious initrd can extract it to
mount actual LUKS volume). It was fixed in cryptsetup, but not sure
about grub LUKS handling.

> As you said, deciding what is worst between computrace/intel me or the
> absence of vt-d2 (interrupt remapping) in an interesting and difficult
> choice to make in the probable attack vectors used against oneself. You
> know any researchers interested in those particular practical questions?

Not really, but maybe Joanna does (cc).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXDrhhAAoJENuP0xzK19csSgEIAJhjf+fLFX0cKB0DONzhHUS7
redJ5DsHI+knPtBFnJDGORMzzhnRn9I3aTrxY0Z3ZM16tdp93euxOh48HOGpN9Nz
1ZBGw8i/PfD0V6CdacjTNMbE8vp/h2ugvY4D66+UN7p1l+Yt2Ty86Mnb3Q74xMuT
vfjLjmnEdkDjr7nJgGqd+1pvb8YWTZvU8q034eNgleIoncil1n7bvkqgeuLPCY64
Wp+nsbk4975aTBs5Sz6QdTAtGyIp2lKHBhpZ0eF7m65wMn3s3XBAtFxMQ6NZZ1o8
+6WlvTNxie6zfqoGowkYLPOEhtZby840WwzbnJ5spjlHdbzHpVAqDl8d9Yt/HjA=
=uM9/
-----END PGP SIGNATURE-----