What are we gonna do about Intel's move to kill off LegacyBios before 2020?

[Yuraeitha]

This is some months old news now from November 2017, and may already be in the plans to fix, however, I'm putting this forward as I'm not aware of any existing discussions on the matter, this is only an insurance so that we're not caught un-prepared for Intel's frustrating lock-in move. I apologize if it's already being discussed internally. Nonetheless, that being the case, this post can also serve as a heads-up to others in the community to be prepared for a new extra hardware issue angle.

http://www.zdnet.com/article/intel-were-ending-all-legacy-bios-support-by-2020/

Articles like these, seem to point towards that Intel is making a move to remove LegacyBIOS completely. This by all appearances appear like it could become a major headache for many Qubes users on new hardware in the near-term future, considering some Intel devices are already taking this step to be ready by 2020 already now.

Ignoring the otherwise important issue of the locked hardware/software blobs for a moment. Not solving this boot issue on time soon, seems like it might cause a big problem for many, many existing and new Qubes users getting new expensive hardware, if something isn't done to prevent or minimize it.

Hardware compatibility is already an issue, Intel's move here just seems to make it worse.

What can be done to solve this? Qubes/Xen would need better UEFI support? If answers have been found, is it something that possibly can be shared with us to ease the coming worries a bit?

[Marek Marczykowski-Górecki]

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

Generally Qubes OS and Xen do support UEFI, so this is not a blocker.
But there are some problems with various UEFI implementations, and also
with Xen inferior UEFI support. One of issue is combination of Grub(2) +
non-multiboot-compatible xen.efi. For Qubes OS 4.0, we've solved it by
removing grub from the picture[1]. But latest Xen version do support
multiboot, so better solution is on the horizon (Qubes OS 4.1?).

[1] https://github.com/QubesOS/qubes-issues/issues/3505

- --
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-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqlSIMACgkQ24/THMrX
1yy0Twf/c2sxT6LG9k9mQw5M47CwGXsnvVRc+0JAgvnX/Ht9RLSl79ok9QQMvgps
u4RcmS4akv7YI1/vXKAt5ziUk6Jv2+Zd0Y8OIP8YPGHxxc0xF4CUS1AUt4yjrEh6
amcAxW0X1PiCyiyCR9LnVktXVPV7MyDu6xUJ13jaQKFAaIddZjwJNovmW9ZqsA8H
vjvNdoJTbq8gVU10x64cYU7hECJDQgAJVWRlepsWKy6Trffn8+2zSuAXHaLRr2mj
UelBFGE0XspPlWHvWjLKuEeTS1ShsFvpRNPxCMfjEXFgUQFLLzGU28gV5ndVH/4Y
BkZxKQBBHcbPl6vPqEiL7TuBmHylOw==
=4Nf2
-----END PGP SIGNATURE-----

[Yuraeitha]

Thanks Marek, it's very comfortable knowing that you're still working on further improving the booting mechanisms, this puts worries for the future at ease. Greater UEFI compatibility certainly will help making it less expensive or risky in finding new unreported HCL hardware in the future, removing or reducing one of the new hardware complexities when hunting for Qubes hardware.

As always, thanks for the amazing work you guys put into making Qubes OS.

[Tai...@gmx.com]

Lets not use Intel's terms here, use "BIOS" instead of "LegacyBIOS" UEFI
is not at all better.

Remember folks if something is truly a good thing people don't need to
be forced to use it.

As always I suggest encouraging the xen developers to accept help (from
raptor and IBM) to port xen to POWER and I also suggest the purchasing
of non-x86 owner controlled libre products like the OpenPOWER9 TALOS 2
for your virtualization needs which will support the future development
of a POWER laptop.

[awokd]

On Fri, March 16, 2018 2:50 pm, Tai...@gmx.com wrote:

> As always I suggest encouraging the xen developers to accept help (from
> raptor and IBM) to port xen to POWER

When I felt them out on it, I got the impression they were welcoming help
from anybody on porting Xen to POWER.
https://www.mail-archive.com/xen-...@lists.xenproject.org/msg08625.html

Everyone's too busy now, but is there a long-term/blue-sky vision of Qubes
on non-x86 architectures, whether ARM, POWER or some other? Is that where
Qubes Air comes in? Staying true to the concept of isolating data from
exploited hardware seems to only be getting more difficult on x86. I've
read through some of the discussions on here about ARM, but (open)POWER
products are still pretty new.

From Qubes' perspective, which arch. would make the most sense to pursue
long-term?

[Yuraeitha]

Another futuristic perspective to think about in addition, is whether Qubes OS one day can function on the architectures of smartphones. For example, it might not be so much 're-inventing the wheel' work to get i.e. android working which already has all the needed phone software build into it, making it easier to get started. (And android can already boot in Qubes VM's). It would also be easy to switch the phone software, kind of like it's easy to switch the hyper-visor or templates in Qubes, so the concept isn't very foreign to what Qubes is already doing on pc hardware. It'd be quite interesting if it was possible to have something like a QubesPhone, or whatever it would be called. I do by no means have the right insight, but I imagine the biggest hurdles would be the hyper-visor architecture support on smartphone hardware, passing the second CPU chip (essentially the unwanted but forced spyware blobs) tunneled securely to the android AppVM, as well as building Qubes tools to function with touch-screen, etc.

For example, the unwanted spyware second cpu blobs could be put in the phones equivalent to pc's sys-net, befind a sys-firewall.

By all appearances we're moving towards an age where laptops one day not too far into the future will stop to exist altogether in favor of smartphone acting as a laptop, and instead connect to a bigger screen/keyboard/mouse with the smartphone. It'd be extremely interesting if this would one day be possible to do with Qubes.

Smartphones are catching up too, at some point soon normal user wouldn't need all that computing power that can be put into phones, and for some users that's already the case already now.

Qubes OS also seems more immune to failure here unlike Oracles Ubuntu phone failure, and the many others out there that failed. I mean, if small work can be done here and there, some day we might not need much to start installing Qubes on smartphones. Having the ability to shutoff microphone/camera/gps when not used is also extremely ideal, at the very least pulling it from android when not used (the second cpu spyware chip might be harder to block though).

@Tai...@gmx.com
I can work with that, I'll call it BIOS instead on-wards.

[Tai...@gmx.com]

On 03/16/2018 11:52 AM, 'awokd' via qubes-devel wrote:

> On Fri, March 16, 2018 2:50 pm, Tai...@gmx.com wrote:
>
>> As always I suggest encouraging the xen developers to accept help (from
>> raptor and IBM) to port xen to POWER
> When I felt them out on it, I got the impression they were welcoming help
> from anybody on porting Xen to POWER.
> https://www.mail-archive.com/xen-...@lists.xenproject.org/msg08625.html

Timothy Pearson from raptor said otherwise :[ that the devs didn't
accept the support advances from raptor and IBM.
If you want I can email you the TALOS 2 IRC chatlog - it is massive so
it must be send as an attachment.

I would say one of the main issues now is people not buying the TALOS 2
because they couldn't use qubes, kind of chicken and egg problem - to
which I reply that if no one buys the T2 it will be the end of owner
controlled high performance computing and eventually the end of owner
controlled computing in general even being able to run your own apps or
unsigned apps will be prohibited in wintels vision of the future.
Whereas if people buy a TALOS 2 there are plans for a TALOS bricktop
(similar to how laptops were in the mid 90's) and eventually a normal
mobile workstation style POWER laptop in addition to the TALOS 3.

I encourage everyone to purchase it anyway and make due POWER-KVM/QEMU
which still enables you to create a very capable (and fast)
virtualization setup, you would have much better security with that than
with qubes running on a ME/PSP computer or an old post-support x86 device.

The TALOS 2 board/cpu costs less than an intel xeon setup with
equivilant performance and features and is about the same price as a two
KGPE-D16 boards with new dual processors (the last and  best owner
controlled x86 board)

I will be getting one and using it for a qubes style virtualization
setup when I get a decent job.

> Everyone's too busy now, but is there a long-term/blue-sky vision of Qubes
> on non-x86 architectures, whether ARM, POWER or some other? Is that where
> Qubes Air comes in? Staying true to the concept of isolating data from
> exploited hardware seems to only be getting more difficult on x86. I've
> read through some of the discussions on here about ARM, but (open)POWER
> products are still pretty new.
>
> >From Qubes' perspective, which arch. would make the most sense to pursue
> long-term?

POWER is the only performance owner controlled arch and the only one
that makes sense as it has a OEM that is becoming more open rather than
less open and they actually listen to what the customers and vendors
want, raptor engineering (makers of TALOS 2 and various coreboot stuff)
managed to convince IBM to open source a variety of things beyond what
they were already doing.

Hilarious that IBM of all companies is the one to save computing freedom :0

https://www.mail-archive.com/xen-...@lists.xenproject.org/msg08801.html
"That's indeed an issue. There are ARM64 SoCs which are very capable and
could easily match or even outperform commodity Intel desktop hardware,
but no-one offers them in a desktop or workstation package. I guess the
seemingly dwindling desktop market is not very attractive to vendors."
Gigabyte sells the MP30, an AppliedMicro ARM CPU device
server/workstation board - 16 cores that compare to a sandy bridge
device no idea if it has ARM's IOMMU equivilant however (the GIC V3)

On 03/16/2018 01:49 PM, Yuraeitha wrote:

> For example, the unwanted spyware second cpu blobs could be put in the phones equivalent to pc's sys-net, befind a sys-firewall.

That is impossible - at least I don't know of any phone SoC's don't have
IOMMU's let alone one in common use.
Btw by default the linux kernel restricts DMA if an IOMMU is present so
you don't really need sys-net what that does is prevent errors in the
networking code/drivers from being able to exploit the main system - its
purpose isn't to prevent DMA exploits.
AFAIK the baseband is equivilant to an Intel ME/AMD PSP type system in
that it always has access to the main memory, cpu and peripherals.

As of now I would go with a replicant compatible phone such as the
galaxy S3 which supports open source firmware for the baseband (phone ME
slash modem) which negates almost all concerns that would require a sys-net.

Android can limit application capabilities so I really don't think this
is needed at all especially when compared with urgent things like POWER.

> By all appearances we're moving towards an age where laptops one day not too far into the future will stop to exist altogether in favor of smartphone acting as a laptop, and instead connect to a bigger screen/keyboard/mouse with the smartphone. It'd be extremely interesting if this would one day be possible to do with Qubes.

It won't as they will use hardware code signing enforcement to deny you
your own OS.
Intel ME/AMD PSP is only the beginning of the gradual revoking of
computing rights, one day you will only be allowed to run windows and
install approved apps from the windows store - microsoft is already
planning this - unless you pay for a "developer" PC.

How does intel/amd expect people to learn how to program firmware for
x86 without selling owner controlled machines that have or at least
support libre firmware? who knows.

> Smartphones are catching up too, at some point soon normal user wouldn't need all that computing power that can be put into phones, and for some users that's already the case already now.
>
> Qubes OS also seems more immune to failure here unlike Oracles Ubuntu phone failure, and the many others out there that failed. I mean, if small work can be done here and there, some day we might not need much to start installing Qubes on smartphones. Having the ability to shutoff microphone/camera/gps when not used is also extremely ideal, at the very least pulling it from android when not used (the second cpu spyware chip might be harder to block though).
>
> @Tai...@gmx.com
> I can work with that, I'll call it BIOS instead on-wards.

Yay :D its also why I say "IOMMU" instead of "VT-d" many lazy/uniformed
people think that it is an only intel technology and have no idea that
all other modern CPU's can have it including POWER (POWER-IOMMU) and ARM
(GIC V3)

[Tai...@gmx.com]

I believe soon we will be seeing an "Intel will be forcing Secure Boot
by 2025" news article with all the usual talking head idiots saying that
such a thing is fine because red hat provides a signed kernel and grub
so you can "still run linux" (their linux, not yours)
I believe by 2030 only "business" expensive laptops will allow you to
run linux....gotta love the change over to non-owner controlled right?

ARM laptops are also good if they use an owner controlled high
performance CPU design from a reputable company, there are some decent
ones from AppliedMicro that are as fast as a 4 core sandy bridge CPU
when you combine all 16 cores.

I believe one of the ways forward is making a 1U open laptop design that
can accept any standard ATX motherboard, this would mean being able to
use many of the superior non-x86 owner controlled desktop embedded
boards like the performance ARM boards from gigabyte (ex: the MP30)
which support uboot so as to not get locked in to intel's terrible uefi
ecosystem.

If the TALOS 2 is successful there are plans for a TALOS bricktop
apparently....heres to hoping many people buy the T2! (and get to enjoy
the speed and freedom)

[Thierry Laurion]

Would love to read that irc log.