Le lun. 28 mars 2016 à 22:13, Thierry Laurion < thierry...@gmail.com> a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Mar 29, 2016 at 12:50:24AM +0000, Thierry Laurion wrote:
> Le lun. 28 mars 2016 à 05:09, Marek Marczykowski-Górecki <
> marm...@invisiblethingslab.com> a écrit :
>
> > -----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.
> >
>
> 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? ;)
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
> 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-----
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 |