Linux 4.14 Dropping In-Tree Firmware

[andyprough]

yes, but your post is stupid
it does not make it easier to separate, they were already separated in firmware directory. and this is only source, binary kernel will have firmware installed anyway, just from other git repo

This change will save some time in the building of the Linux-libre kernel. Might be able to do away with some of the de-blobbing scripts. His post was not stupid.

[MoonMoon]

I'm aware of those and I said "x86-based" because I also play games. The point is that I'm probably going to have to maintain two separate systems to satisfy myself. One expensive non-x86 one for day-to-day use and one router-quarantined x86 machine next to it for gaming.

(If that winds up happening, I'll probably go for an Intel CPU for my gaming machine since I like to emulate for some of my games rather than relying on aging console hardware and, last I checked, Intel still had better single-thread performance.)

*sigh* It'll be hard enough just saving up for the non-x86 hardware.

I don't get it. Unless all of your games are open source (and as such can be compiled for the power architecture), it isn't it moot to use a system free of blobs? Assuming that you mean: "I need x86 because the games I play are closed source and I can't recompile them for Power", then why would you need a blob free system?

[Kekos]

Does this mean that the linux git tree will be the equivalent of linux libre (blob free) ?

[starshipeleven]

I don't get it. Unless all of your games are open source (and as such can be compiled for the power architecture), it isn't it moot to use a system free of blobs? Assuming that you mean: "I need x86 because the games I play are closed source and I can't recompile them for Power", then why would you need a blob free system?

Because compartmentalization is what you do when you can't have a safe system. I also have a similar setup (on a dualboot system, I would also like the Power but it's out of my budget for now).
The thing here is that all important stuff and internet activity happens from the (safe) Linux system, while the windows system (untrusted) is used only for games where you don't really care if Win10 phones home and tells Microsoft how much hats you have in Team Fortress or something.

Same for IOMMU (Intel VT-d or AMD Vi are commercial names, Power just calls it IOMMU which is the generic name), it compartimentalizes stuff on PCIe, so as long as the CPU/board firmware is trusted then any GPU will live in its own "compartment" and its firmware can't tell it to come and read my stuff through DMA.

The main point here is that with the ME/PSP bullshit I can't really trust my fucking CPU on x86 (and also on ARM unless I bought the chips and blew the fuses myself), while on Power the board firmware is still open and therefore trustable.

Same thing for his mention of routers to isolate its network, still making compartments. A router (and firewall) compartimentalizes the network used by untrusted systems, so that they won't just be able to scan your home network or try to spread malware or whatever. Also a router can block any communication on known ME/PSP ports, which is already better than nothing.

And note that compartmentalization is (or should be) done all the time at work places too because you will always have systems that have total crap security (PCs running XP for some reason, industrial equipment that is remote-pwnable since 1999 but being industrial equipment you can't just update it, and so on) and you want to keep them safe and operational, or at the very least to not allow them to compromise other systems.

[chithanh]

Same for IOMMU (Intel VT-d or AMD Vi are commercial names, Power just calls it IOMMU which is the generic name), it compartimentalizes stuff on PCIe, so as long as the CPU/board firmware is trusted then any GPU will live in its own "compartment" and its firmware can't tell it to come and read my stuff through DMA.

I'd caution against the line of thinking that the mere existence of an IOMMU on a system will make things secure. In practice, IOMMUs have bugs, system firmware has bugs, and operating systems have bugs. And even if all were bug-free, early-boot attacks against IOMMUs have been demonstratred.

[ssokolow]

I don't get it. Unless all of your games are open source (and as such can be compiled for the power architecture), it isn't it moot to use a system free of blobs? Assuming that you mean: "I need x86 because the games I play are closed source and I can't recompile them for Power", then why would you need a blob free system?

It's not about being free of blobs, it's about the ME/PSP being un-audited closed-source software running at higher privilege than my OS itself.

With the pre-PSP, pre-UEFI system I'm running now, my OS is the most privileged thing that's consistent enough across multiple machines to be a viable target for non-personal attacks and, paired with the IOMMU, I can have a reasonable expectation of trust.

[starshipeleven]

I'd caution against the line of thinking that the mere existence of an IOMMU on a system will make things secure. In practice, IOMMUs have bugs, system firmware has bugs, and operating systems have bugs.

Thanks for your reminder that nothing is perfect, but a system with IOMMU is still far far better off than one without.

And even if all were bug-free, early-boot attacks against IOMMUs have been demonstratred.

"early-boot attacks against IOMMU" actually are firmware exploits targeting (UEFI) bugs, it's not a IOMMU flaw, it's firmware-grade malware.

Which is why I say I want an opensourced firmware. That way it can be patched, and won't be insta-pwnable in 3 years tops (most UEFI don't even last that long, there are enough new firmwares with the same long-standing bug as the older ones).

[chithanh]

"early-boot attacks against IOMMU" actually are firmware exploits targeting (UEFI) bugs, it's not a IOMMU flaw, it's firmware-grade malware.

I specifically said there was no bug in the IOMMU or elsewhere. The particular attack was controlling IOMMUs before the operating system could, and hiding the existence of IOMMUs partially or entirely from the operating system. E.g. hardware has 8 IOMMUs, but early-boot malware (from PCI option ROM or elsewhere) hides one so that the OS thinks that only 7 exist. 8th IOMMU is then available to use by malware.

[starshipeleven]

I specifically said there was no bug in the IOMMU or elsewhere. The particular attack was controlling IOMMUs before the operating system could, and hiding the existence of IOMMUs partially or entirely from the operating system. E.g. hardware has 8 IOMMUs, but early-boot malware (from PCI option ROM or elsewhere) hides one so that the OS thinks that only 7 exist. 8th IOMMU is then available to use by malware.

It was malware interacting with or compromising the board firmware (which is responsible of hardware initialization and can initialize hardware wrong if told to), IOMMU was just one of the possible things that could have been tampered with afterwards.