1 |
On Fri, 2021-07-23 at 20:44 +0900, Alice wrote: |
2 |
> On 7/23/21 8:29 PM, Ulrich Mueller wrote: |
3 |
> > > > > > > On Fri, 23 Jul 2021, Alice wrote: |
4 |
> > |
5 |
> > > On 7/23/21 6:04 AM, Ulrich Mueller wrote: |
6 |
> > > > Maybe this is a stupid question, but what is USE=deblob doing these days |
7 |
> > > > anyway? I thought that all nonfree firmware had been removed from the |
8 |
> > > > kernel tree (with version 4.14) and was provided separately by the |
9 |
> > > > sys-kernel/linux-firmware package? |
10 |
> > |
11 |
> > > There are still users that want a full libre(deblob) kernel. |
12 |
> > > There are also distributions built around libre(deblob) kernel. |
13 |
> > > deblob is still removing many modules from the kernel that are non-free |
14 |
> > > you can see for exemple is removing things also on most recent kernels |
15 |
> > > https://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/5.13-gnu/deblob-5.13 |
16 |
> > |
17 |
> > I know, but I still wonder what it actually does. I've checked the first |
18 |
> > 10 or so files in their list, and they all say in their header that they |
19 |
> > are under a free software license. So does that mean the license info in |
20 |
> > these files is wrong? If not, then why is the script touching them? |
21 |
> > |
22 |
> > Also, (e.g.) this: |
23 |
> > |
24 |
> > > announce MICROCODE_INTEL - "Intel microcode patch loading support" |
25 |
> > > reject_firmware arch/x86/kernel/cpu/microcode/intel.c |
26 |
> > > clean_blob arch/x86/kernel/cpu/microcode/intel.c |
27 |
> > > clean_blob arch/x86/events/intel/core.c |
28 |
> > > clean_kconfig arch/x86/Kconfig MICROCODE_INTEL |
29 |
> > > clean_mk CONFIG_MICROCODE_INTEL arch/x86/kernel/cpu/microcode/Makefile |
30 |
> > |
31 |
> > IIUC, it will disable CPU microcode updates. The code being removed is |
32 |
> > entirely free (but it could load some non-free third-party microcode). |
33 |
> > Do we really endorse that, from a security (spectre, meltdown, etc.) |
34 |
> > point of view? Note that the ex-factory microcode of these CPUs is |
35 |
> > already non-free, so arguably rejecting updates for it doesn't change |
36 |
> > anything. |
37 |
> > |
38 |
> > Ulrich |
39 |
> > |
40 |
> |
41 |
> |
42 |
> Gentoo is about choice. if there are users that want to use deblob I |
43 |
> don't see why we don't have to add the option. |
44 |
> |
45 |
> do you want to suggest any warn message that deblob option can give from |
46 |
> a security point of view ? |
47 |
|
48 |
If deblob indeed makes things vulnerable, it must be at least masked via |
49 |
use.mask. |
50 |
|
51 |
-- |
52 |
Best regards, |
53 |
Michał Górny |