Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

On 7/23/21 9:41 PM, Michał Górny wrote:

On Fri, 2021-07-23 at 20:44 +0900, Alice wrote:

On 7/23/21 8:29 PM, Ulrich Mueller wrote:

On Fri, 23 Jul 2021, Alice  wrote:

On 7/23/21 6:04 AM, Ulrich Mueller wrote:

Maybe this is a stupid question, but what is USE=deblob doing these days
anyway? I thought that all nonfree firmware had been removed from the
kernel tree (with version 4.14) and was provided separately by the
sys-kernel/linux-firmware package?

There are still users that want a full libre(deblob) kernel.
There are also distributions built around libre(deblob) kernel.
deblob is still removing many modules from the kernel that are non-free
you can see for exemple is removing things also on most recent kernels
https://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/5.13-gnu/deblob-5.13

I know, but I still wonder what it actually does. I've checked the first
10 or so files in their list, and they all say in their header that they
are under a free software license. So does that mean the license info in
these files is wrong? If not, then why is the script touching them?

Also, (e.g.) this:

announce MICROCODE_INTEL - "Intel microcode patch loading support"
reject_firmware arch/x86/kernel/cpu/microcode/intel.c
clean_blob arch/x86/kernel/cpu/microcode/intel.c
clean_blob arch/x86/events/intel/core.c
clean_kconfig arch/x86/Kconfig MICROCODE_INTEL
clean_mk CONFIG_MICROCODE_INTEL arch/x86/kernel/cpu/microcode/Makefile

IIUC, it will disable CPU microcode updates. The code being removed is
entirely free (but it could load some non-free third-party microcode).
Do we really endorse that, from a security (spectre, meltdown, etc.)
point of view? Note that the ex-factory microcode of these CPUs is
already non-free, so arguably rejecting updates for it doesn't change
anything.

Ulrich

Gentoo is about choice. if there are users that want to use deblob I
don't see why we don't have to add the option.

do you want to suggest any warn message that deblob option can give from
a security point of view ?

If deblob indeed makes things vulnerable, it must be at least masked via
use.mask.

sorry, I rephrase my answer.


--
Thanks,
Alicef

Is not deblob that makes things vulnerable, as deblob is just removing what is non-free code in the kernel, but not having CPU microcode updates it may make the system vulnerable. You should still be able to update microcode and than use a libre kernel without security issues.

OpenPGP_0x1D6802D75C10FEF6.asc
Description: application/pgp-keys

OpenPGP_signature
Description: OpenPGP digital signature