Research support for libreboot/coreboot-based systems

[marmarek]

According to user reports it doesn't work.

Did anybody complete with success Qubes installation on Librebooted laptop?

I tried verison 3.1 from usb stick, and 3.0 from 2 different dvd's and it didn't boot at all. Live 3.0 also did not start.

I also tried connect hdd with already installed Qubes - also no success with booting.

Related: #1131

[mfc]

@isislovecruft any luck with your coreboot+Qubes set-up since Congress?

[FlorianHeigl]

I'm also not able to boot off a dvd to the installer, X200 with libreboot.
Just got a new drive hoping that'd help but doesn't.

[tlaurion]

Which model? (See dmidecode output from a livecd)

What cpu microcode do you have?
dmesg | sed -n 's/^.* microcode: CPU0 sig=0x([^,]),.$/\1/p'

Do you have dmar error from livecd boot?
dmesg | grep -I dmar

It seems that dmar initialisation is incomplete from coreboot/libreboot. I
also got weird results from different x200 models having latest lenovo bios
update. Trying to compile those results from a bunch of x200 laptops I
ordered on the Internet.

From my experiments, there is some issues with xen and lenovo gm45/Penryn
cpu/ i915 graphic chipset.

Putting iommu=0 on the xen boot line resolved the issues but that also
means incomplete security from pci devices isolation.

Iommu=no-igfx permits xen to boot and system installation but will hang at
netvm and usbvm pci pass-through initalisation/device usage .

I need help to troubleshoot the issues accordingly.

See this thread:
https://groups.google.com/forum/m/#!msg/qubes-users/bHQHjXqinaU/u4hzYo8yBQAJ

I have hope those devices can be supported.
Thierry
Le sam. 9 janv. 2016 11:16, Florian Heigl [email protected] a
écrit :

I'm also not able to boot off a dvd to the installer, X200 with libreboot.
Just got a new drive hoping that'd help but doesn't.

—
Reply to this email directly or view it on GitHub
#1594 (comment)
.

[tlaurion]

I could recommend to flash libreboot after having installed qubes as a working workaround, if that is feasible to you.

Keep in mind that vt-d is not supported at the moment from libreboot, and that vt-x depends of the microcode update version, as per my previous post.

[isislovecruft]

@mfc: There were several coreboot issues with raminit on a Thinkpad x220, which (so far) are seemingly unrelated to QubesOS. There are probably still quite a few issues with coreboot RAM initialisation on x220, given that the example issues which I hit included:

• "I have two sticks of RAM",
• "I have two sticks of RAM of different sizes", and
• "I have a total amount of RAM greater than the 'recommended' 8GB".

Despite the issues with raminit, VT-x and VT-d were supported, and (when the laptop did successfully initialise the RAM and successfully boot) the Xen hypervisor was exec'd successfully as well. So, theoretically, it does work (if you enjoy fully powercycling your machine ~30 times to get it to boot).

[tlaurion]

X200 limitations:

• CPUID1067a required for virtualisation to ~work without microcode updates.
• vt-d1* could be supported with more work from coreboot. (vt-d1 means no interrupt remapping. HCL script should detect and warn about this.)
• Libreboot needs to be installed in version libreboot-r20150518fix-562-g179b5ba to have seabios payload optional. Qubes cannot boot from GRUB's isolinux scripts, out of meory errors happen.
• Alternatively, one can build x200 libreboot himself and add seabios by himself with this script
• Anaconda bootloader.py functional patchwork was tested and posted here to be able to boot a from within a luks container from coreboot (libreboot was tested). This was refactored and included with Qubes 3.2.

As a result, one can presently install Qubes inside a fully encrypted disk. Boot from libreboot into a password protected GRUB that only permits to boot from that luks container through a passphrase that unlocks and boots the system where, unfortunately, real full device isolation is not possible.

*vt-d1 (vt-d2 has interrupt remapping) on x200/t400 has issues with i915 driver and memory region corruption without libreboot being installed. Actual libreboot is the functional equivalent of putting iommu=0 on the xen boot line, putting device isolation off. Still, this is better then having normal OS operating.

The question of choosing what threat vector could hit you is a hard one and seems to be based on one's personal beliefs: Intel ME/computrace administration injected malwares or vt-d1 device isolation vulnerabilites (not supporting interrupt remapping)

A laptop permitting interrupt remapping (vt-d2) but not having ME is impossible to find. Purism 13 makes no exception (!NOT TRUE FOR SANDY/IVY BRIDGES EG LIBREM 13V1 OR X230 X220 ETC where ME is neutered+deactivated!). Until people create real alternatives enforcing IOMMU and virtualisation, it seems we will have to choose between old hardware without ME/Neutered ones (ivy/sandy bridges) with different levels of device isolation or recent hardware enforcing both (FSP blobs, ME blobs, MRC memory init blob, and other blobs included in coreboot configs for hardware to initialize)

EDIT: The X200 and other models not having vt-d2 don't meet QubesOS 4 requirements

[osresearch]

Other than video glitches during bootup, my x230 (4 GB, i5-3320) is running Qubes 3.1 successfully and CoreBoot boots reliably. I had previously installed Qubes on the system, so I'm not sure if the install process works.

[mfc]

hi @osresearch that's great! and thanks for your qubes-devel list emails giving further details. it's not clear to me if current coreboot git head is sufficient or if your patches are necessary as well? Could you draw up some basic documentation on how to get from vanilla x230 to there so that less skilled folks can test it out?

[osresearch]

My totally not-ready-for-prime-time tree is here: https://github.com/osresearch/heads

If you run make in the top level directory, it will download (and verify hashes) on coreboot, linux, tpmtotp, kexec, busybox, gcc, xen, etc and after a few hours will hopefully build a very minimal coreboot + linux + initrd image that can then be flashed onto the 4MB chip on the motherboard (leaving the ME firmware and flash descriptor intact in the 8MB chip). I'm using my own flasher, https://trmm.net/SPI since the buspirate ASCII protocol is slow and flashrom has issues with writing only part of a chip.

My TPM patches for coreboot are not yet stable. I'm poking at it in the romstage and need to figure out how it interacts with S3 resume.

[tlaurion]

@osresearch: awesome work.

[tlaurion]

This high level design for vIOMMU is an interesting thing to watch for Libreboot support (old machines not supporting vt-d interrupt remapping)

https://www.mail-archive.com/[email protected]/msg78654.html

I have not read it throughfully yet, but that made me wonder: "3.3 Interrupt remapping
Interrupts from virtual devices and physical devices will be delivered
to vlapic from vIOAPIC and vMSI. It needs to add interrupt remapping
hooks in the vmsi_deliver() and ioapic_deliver() to find target vlapic
according interrupt remapping table."

[zamaudio]

I am running x220 with me_cleaner and when I flashed seabios instead of grub2 payload into my coreboot, I am able to boot the 3.2 installer. Will try to install soon

[zamaudio]

By the way, I submitted a patch ages ago to fix DMAR table in X200, so VT-d1 works on X200 with coreboot and no ME, see https://review.coreboot.org/#/c/16330/ ... also, there might be some way to fix the graphics corruption on IGD if someone considers pursuing my old patch that got abandoned: https://review.coreboot.org/#/c/17645/

[Buom01]

For people interested: http://dodoid.net/qubreboot/ - An easy way to install Qubes OS on T400 Libreboot -

[h01ger]

On Tue, Mar 20, 2018 at 10:07:24AM -0700, Bastien ADAM wrote: For people interested: http://dodoid.net/qubreboot/ - An easy way to install Qubes OS on T400 Libreboot -

I'm rather interested why you cannot use a seabios payload in libreboot and then boot a usbstick with a qubes iso? and then I find it utterly ironic that the site requires me to run random javascript code for no reason., though i'm not sure the following wget fails because of javascript or because of using tor or simple because a server misconfiguration: user@host:~$ wget http://dodoid.net/qubreboot/release/qubreboot-0.1.zip --2018-03-20 18:15:42-- http://dodoid.net/qubreboot/release/qubreboot-0.1.zip Resolving dodoid.net (dodoid.net)... 185.27.134.225 Connecting to dodoid.net (dodoid.net)|185.27.134.225|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2018-03-20 18:17:17 ERROR 403: Forbidden.

…

-- cheers, Holger

[Buom01]

I'm rather interested why you cannot use a seabios payload in libreboot and then boot a usbstick with a qubes iso?

Firstly because latest version doesn't have seabios integrated probably because https://libreboot.org/faq.html#external-gpus
Secondly because reflashing it is risky, also because rebuild it with seabios need to know what we do
Lastly, if something went wrong, it's complex to repair (I haven't the material)

The script runned on qubreboot's download seem to be SlowAES to get a cryptographic alternative to SSL (http://code.google.com/p/slowaes/)
However, you can run

curl -A googlebot http://dodoid.net/qubreboot/release/qubreboot-0.1.zip > qubreboot-0.1.zip

(with useragent to googlebot to avoid scripts and got direct download)

Even if many part of qubreboot's project need to be improved, the script is quite short and quite easily understandable. It's a good (and easy) starting point I think

Sorry for my brief answer, hope I'm understandable and hope I have understood

[tlaurion]

For people interested: http://dodoid.net/qubreboot/ - An easy way to install Qubes OS on T400 Libreboot -

Attention people. The same limitations applies. Qubes 3.2.x will let you install itself because it is less restrictive on IOMMU requirements. But you won't get real IOMMU memory/device isolation, which requires vt-d2 and interrupt remapping, not present on t400/x200 models only supporting vt-d1.

If you want a laptop that supports the same kind of freedom while not being Intel and do not have Intel ME (even if the x230 only has BUP and ROMP) I would suggest to go for the Lenovo G505s AMD based laptop. If you are a developer and own a Lenovo G505s, please help Heads support it!

[tlaurion]

Edited: #1594 (comment)

Let's not forget that in that false "open source" idiom we live in denial in (coreboot is not free anymore with FSP, MRC memory init blob and other blobs in), we silently accept other blobs (even in Linux kernel now) without even questioning them anymore.

CPU microcode updates blobs, EC blobs, disk firmware blobs, iKVM blobs, TPM firmware blobs, etc.

This GitHub physical server probably has all of them excluding EC. Your secured mail server provider. Your VPN server...

We are accepting that silently. We are consequently complicit.

The kgpe-d16, the kcma-d8, the g505s are the last candidates without binary blobs, outside of the EC and microcode updates. And their support from coreboot is fading, with the risk of disappearing soon (amdfam15 will if nothing is done) since support for newer x86 is the main goal of coreboot.

I understand, while disagreeing this false dichotomy. People didn't realise they needed it because they never understood they existed nor why they were important from their freer standpoint. Even open firmware researchers accept blobs, now.

We have to choose to invest energies in x86 alternatives, which implement both IOMMU and virtualization, while not letting die what we currently have which are the most libre that will probably exist on the x86. Amdfam15 and Intel sandy/ivy bridge. That's it. More recent then that and you get a full blown Intel Me or equivalent that can only be gently asked to be deactivated, no more native ram training nor hardware init without binary blobs. That is the reality until we stop denying it and build/support something else.

We should, as open source researchers, even more in the open firmware world, stop supporting newer Intel and AMD platforms until their blobs sources are publicly available without NDA. We should boycott them until they really open their things up. Decide to stop believing in them and their never respected promises. Now an open source onboard certification plan? A logo for open source platforms certification? Please. Open just means less and less.

Else we are complicit in accepting things will just get more closed source. The Open Source firmware community is silently accepting this fact. There is something really wrong happening. There is an elephant in the room!
The emperor is naked!

Can we at least agree on the actual reality? So we restate the need of building from there a real trustable root of trust, this time on real, open source hardware? Or we really are waiting for everything to collapse, being complicit of it...