Security Question
- Anmelden oder Registrieren um Kommentare zu schreiben
I was wondering, for those who have experience with both, how Trisquel stacks up against OpenBSD from a security standpoint ? I believe OpenBSD allows closed source firmware in the kernel where Trisquel does not which is a win for Trisquel but how about in other ways ?
O 17/08/21 ás 19:45, name at domain escribiu:
>I believe OpenBSD
> allows closed source firmware in the kernel where Trisquel does not
OpenBSD does not allow binary blobs (binary drivers in the kernel):
http://www.openbsd.org/lyrics.html#39
> I was wondering, for those who have experience with both, how Trisquel
> stacks up against OpenBSD from a security standpoint ?
> which is a win for Trisquel but how about in other ways ?
I use both, but I don't know exactly how different they are on the
security side. For now neither of my installations have been hacked.
OpenBSD has some advantage, for example that they have more control over
the system, since they develop it. If all your programs work on OpenBSD
I would suggest trying it out.
OpenBSD does not allow binary blobs (binary drivers in the kernel)
Indeed. Nevertheless, that does not contradict what PublicLewdness wrote: "OpenBSD allows closed source firmware in the kernel". It is unfortunately true: https://www.gnu.org/distros/common-distros.html#BSD
That link also explains the different meaning of the term "blob" for Linux and BSD. It mentions that "FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining nonfree programs in their ports system" too.
I am a translator!
Sorry, I am a little confused.
Isn't the kernel a program executed by the main CPU while firmware is a program executed by another processor? If so, in what sense can firmware be "in the kernel"?
Firmware is loaded onto a chip by the kernel. In general firmware files are located in a directory (/lib/firmware on Linux, /etc/firmware on OpenBSD) where the kernel can find them. My understanding is that Linux includes some firmware blobs that are hardcoded in the source code and compiled into the kernel (see https://wiki.debian.org/KernelFirmwareLicensing, although this is outdated, I think the vast majority have been removed). As far as I know the firmware included in OpenBSD is all in some separate directories that can easily be stripped.
I found what appear to be proprietary blobs in Linux-libre (though probably not Trisquel's kernel, because Debian strips these files):
arch/powerpc/platforms/8xx/micropatch.c
drivers/media/i2c/vs6624.c
PowerPC is a completely open architecture if I recall correctly. That's probably libre firmware.
Here's the file, it has some Motorola microcode embedded in it and I don't see any source code for it: https://github.com/torvalds/linux/blob/master/arch/powerpc/platforms/8xx/micropatch.c. The same file is present in Linux-libre, unaltered.
On Debian's wiki this file is listed as nondistributable.
I am a translator!
Thanks for explaining and showing an example of the "firmware in the kernel".
One more question: why isn't this in a file that is read by the kernel during execution, instead of putting it in the kernel code (since that this not code to be executed by CPU that runs the kernel)? Or is that actually not going into the kernel binary?
I don't think there is any good reason for it. The vast majority of the firmware is in files that are read by the kernel, but there are a few exceptions in Linux, and they would go in the kernel (or kernel module) binaries if you built with those drivers enabled. Here's a list of the sourceless blobs that I'm aware of. All are removed in Debian's kernel.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/platforms/8xx/micropatch.c (present in Linux-libre)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/usb/dvb-usb/af9005-script.h
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/i2c/vs6624.c (present in Linux-libre)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/appletalk/cops_ffdrv.h
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/appletalk/cops_ltdrv.h
The last two of these are the only ones that have a nonfree license header.
The rest, which have a GPL license header, may actually be non-distributable, since they don't come with full source code which is required under the terms of the GPL.
Besides the sourceless firmware issue, there are also some NVIDIA drivers which are ostensibly under a free license, but according to Debian contain obfuscated source code and are thus nonfree. Both are present in Linux-libre.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev/nvidia
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev/riva
As I said, while OpenBSD does come with proprietary firmware, I'm not aware of any that is actually compiled into its kernel.
Just because you don't see the source code for it doesn't mean it's not available. We've gone over this many times in this forum - the Linux-libre team tends to spend more time and cut more from the kernel than the Debian team. I highly doubt they are overlooking a non-free blob here.
But, you never know. If anyone knows how to track down jxself, I'm sure he could look into it or give a better explanation.
If it is free software, then it needs to at least come with clear instructions to get the source. I looked at the diff between vanilla Linux and Linux-libre, and there are actually only 3 files containing blobs that they remove (meanwhile, Debian removes 5). The rest of the changes just disable code that loads blobs from an external file.
If it is free software, then it needs to at least come with clear instructions to get the source.
Indeed. Have you presented those issues to Alexandre Oliva (lxoliva [at] fsfla.org), who is, I believe, Linux-libre's main developer?
I started a discussion about this on the Linux-libre mailing list, if anyone's interested in joining. Alexandre Oliva seems to think that these files are OK, but in my opinion at least the first one is a clear-cut case of nonfree microcode.
Update: based on the mailing list discussion, I think micropatch.c will probably be removed, unless somebody is able to obtain the source code (unlikely)
https://lists.nongnu.org/archive/html/gnu-linux-libre/2021-08/msg00015.html
Good detective work Legimet, your work got mentioned on the Phoronix website today: https://www.phoronix.com/scan.php?page=news_item&px=GNU-Linux-Libre-5.14
Some quotes from Alexandra Oliva, giving credit to Legimet for raising this issue that found some code that needed to be stripped out of the current and prior versions of the kernel:
"A little over a week ago, Legimet raised flags on some potential nonfree code in GNU Linux-libre."
"Though some of the issues were about different standards (we don't generally regard poorly documented code or pure data as object code over speculation about the existence of an alternate, preferrable source form), but a couple of the issues turned out to be sourceless object code, and so we started the process of cleaning them up, and of respinning earlier releases that contained them."
"So now we clean up a firmware patch for vs6624 sensors, and several microcode relocation patches for powerpc 8xx. Both are encoded as arrays of numbers in upstream Linux releases. The latter had long seemed suspicious to me, but I had assumed those who started cleaning up Linux before I inherited Linux-libre had good reasons to leave it in. The former was entirely my own mistake. I was likely fooled by apparently discontiguous address ranges, a pattern that suggests register initialization, but the multiple small fragments are actually larger contiguous ranges (thanks, Juca!), shuffled for reasons unknown."
Thanks! Tbh it's the Debian people who found these blobs. I just noticed them because I was looking at the diff between Linux-libre and upstream Linux to check which blobs they remove, and which blobs Debian removes.
The one area of difference I know about is in openBSD's development and use of libressl:
"After the Heartbleed security vulnerability was discovered in OpenSSL [in 2014], the OpenBSD team audited the codebase and decided it was necessary to fork OpenSSL to remove dangerous code." - from wikipedia
Also they developed "doas" as a more secure version of sudo.
Could be a lot of other things, but those are the two I know about.
They forked xdm, the X Display Manager: xenodm.
Really? That's pretty impressive. They do a lot of work it sounds like.
"LibertyBSD is a 'deblobbed' version of OpenBSD. The non-free blobs in OpenBSD have been purged from LibertyBSD, so you can enjoy the benefits of OpenBSD without sacrificing your freedom."
https://libertybsd.net/
It might be a nice option, someday in the future, perhaps more-so for those seeking a setup with extreme minimalism as a goal? Would be cool if they got firejail working on it?
LibertyBSD is also a dead project and refers people to HyperbolaBSD, which itself is not available for use yet, and is a future project of Hyperbola GNU/Linux.
Ultimatey, when HyperbolaBSD gets finished, it WILL be a very cool and interesting OS.
- Anmelden oder Registrieren um Kommentare zu schreiben