Hi Simon, Simon Josefsson <si...@josefsson.org> writes:
> Maxim Cournoyer <maxim.courno...@gmail.com> writes: > >>> An example would be to switch from linux-libre to some 100% free linux >>> kernel that doesn't block nonfree firmware, so if users reluctantly >>> need nonfree firmware they would, on their own, add them. >> >> I thought I'd mention that technically, making it impossible to load any >> firmware in linux-libre is considered a bug, and someone could >> contribute a fix. >> >> Last time I discussed it with the linux-libre, the reason loading >> non-free firmware is outright disabled is because it'd be trivial for >> any privileged (or maybe that's not even a condition?) processes to make >> a system call to Linux to load non-free firmware, which would make it >> difficult to control for users. > > Oh, is that really the case? I had assumed that this was a policy > decision, that linux-libre didn't want to allow users to have the > ability to load non-free firmware, to make sure the goals of linux-libre > aren't compromised. That's a good approximation of the current situation in practice, but in theory they would welcome a solution to having a secure means for users to whitelist some non-free firmware, allowing users to exercise their freedom 0 if so they choose. It's still considered a bug to not have a means to allow users to do what they may want to do, while ensuring the guarantees of linux-libre stand firm even in hostile environment. In 2020 I had an IRC conversation in the #linux-libre channel with lxo and they mentioned that it was still considered a bug, albeit a hard to fix one in a way that wouldn't compromise linux-libre's purpose of safeguarding users from non-free kernel firmware even when it's used in hostile environments. They had hinted as some one-way hashing solution they had proposed that would create aliases for the blobs, and use some associated name in the source. I'm not sure if that can be found one their mailing list. If you have an interest working solving that challenging issue, I'd advise you reach to them and see if you can help :-). > If the reason isn't policy, I don't really understand the privilege > objection. If you would agree that 'root' should be able to load and > run non-free code (which can be rejected on policy grounds), why would > linux-libre prevent that? Is the syscall available for non-root users? > If so isn't that a linux kernel bug, surely non-privileged users > shouldn't be allowed to load firmware that can modify hardware > behaviour? I think it's policy. I probably made things more confused here, by mentioning the privilege. I don't think that's a core issue after re-reading my old IRC logs. > I am personally torn between use of Guix on some machines, where > linux-libre doesn't work, and the alternatives. I've never really liked > the non-guix installation flow (it seems so complicated). I think it is > reasonable in these situations to use a linux-libre kernel but that it > allows loading of non-free blobs, only that I have to do this manually > or specify it separately, and it doesn't happen automatically by > default. This could be part of Guix proper. That could be a middle ground, but since Linux-libre is not against the idea if we find a satisfying, robust and safe way to declare things for a user, it'd be ideal to work toward having that bug #1 fixed at its source. > I have thought that a middle ground project like 'linux-free' would be > possible: it would be identical to linux-libre but re-add the hooks to > allow root to load non-free firmware, if they so chose to do it. I'm > more comfortable with this approach than using linux upstream, since I > think that linux-libre improves more than just non-free firmware > loading. I think some non-free firmware binary gets patched in a few rare places directly in the source (defined as C arrays for example), but other than these few occurrences and disabling the *requests* for the non-free blobs, it doesn't touch other things, IIRC. So in practice if you use Linux and provide just the firmwares you grudgingly decided were worth the security and freedom risks, you are not too far from the middle-ground solution you are describing. > I don't think a strict kernel policy to disallow users to run non-free > code serves user freedom: it would prevent running a binary that I build > using GCC built on a 5 lines C code that doesn't have a license (such a > program would also be non-free). Preventing a program like that from Are you perhaps conflating kernel modules and kernel firmware here? The firmwares are never run on the host directly, but on their target devices. I don't think the problem you described applies here. -- Thanks, Maxim
