A backdoor in xz

Posted Mar 30, 2024 2:22 UTC (Sat) by dvdeug (guest, #10998)
In reply to: A backdoor in xz by DimeCadmium
Parent article: A backdoor in xz

So, do you run the kernel that compressed is 140MB of source (and 100MB of binary)? That's more than Linus's hard drive could hold when he started the project, and 140 times as large as version 1.0. Are you trying to debloat, or are you trying to score points on systemd?

A backdoor in xz

Posted Mar 30, 2024 8:16 UTC (Sat) by DimeCadmium (subscriber, #157243) [Link] (5 responses)

I have 35MB used in /boot, which includes 3 kernels among other things.

A backdoor in xz

Posted Mar 30, 2024 8:24 UTC (Sat) by niner (subscriber, #26151) [Link] (3 responses)

What about kernel modules? They are usually not in /boot.

A backdoor in xz

Posted Mar 30, 2024 21:49 UTC (Sat) by dmoulding (subscriber, #95171) [Link]

As just a random data point, my kernel has all functionality I need built-in to it. I don't even enable loadable module support. The compressed bzImage in /boot is 12M. The uncompressed vmlinux is 41. This is for a desktop with everything that entails (DRM, nouveau, bluetooth, USB, camera/video, audio, etc.)

A backdoor in xz

Posted Mar 31, 2024 1:29 UTC (Sun) by DimeCadmium (subscriber, #157243) [Link] (1 responses)

/lib/modules $ du -hs `uname -r`
64M 6.6.13-gentoo

I'm not sure if you're aware of `make menuconfig`, but unlike systemd, you actually CAN effectively turn off parts of the kernel that you don't need.

A backdoor in xz

Posted Mar 31, 2024 1:31 UTC (Sun) by DimeCadmium (subscriber, #157243) [Link]

Oh and here's the actual modules BTW:

700K 6.6.13-gentoo/misc/vboxdrv.ko
48K 6.6.13-gentoo/misc/vboxnetflt.ko
20K 6.6.13-gentoo/misc/vboxnetadp.ko
59M 6.6.13-gentoo/video/nvidia.ko
8.0K 6.6.13-gentoo/video/nvidia-peermem.ko
1.7M 6.6.13-gentoo/video/nvidia-modeset.ko
16K 6.6.13-gentoo/video/nvidia-drm.ko
2.5M 6.6.13-gentoo/video/nvidia-uvm.ko

A backdoor in xz

Posted Mar 30, 2024 15:10 UTC (Sat) by dvdeug (guest, #10998) [Link]

To carry on with niner's point, /boot/vmlinuz-6.7.9-amd64 may be nine megabytes, but /lib/modules/6.7.9-amd64/ is over a hundred. You could read through the kernels of Unix v6 (the Lions book), or xv6, or Minix. Even twenty years ago, the kernel was so big that the SCO mess turned up a copy of Unix malloc buried in kernel that no one had noticed, even though it should have been replaced with standard kernel functions. Should we use a tighter (less functional) kernel that's actually readable? I don't want to give up a lot of the features I use, but there's certainly no one with the headroom to completely understand 140 MB of source code.

A backdoor in xz

Posted Mar 30, 2024 13:24 UTC (Sat) by pawel44 (guest, #162008) [Link] (2 responses)

Kernel is not pulling third party dependencies.

A backdoor in xz

Posted Mar 30, 2024 14:38 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

Well, not when building it. Running it is another matter, as it pulls in a heap of pre-built binaries (firmware) with poorly-documented provenance.

A backdoor in xz

Posted Mar 30, 2024 15:05 UTC (Sat) by marcH (subscriber, #57642) [Link]

Running it is another matter, as it pulls in a heap of pre-built binaries (firmware) with poorly-documented provenance.

Even worse: it does not even _log_ what it loaded! I usually carry this hack:

--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -562,7 +562,7 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv,
                size = rc;
                rc = 0;
 
-               dev_dbg(device, "Loading firmware from %s\n", path);
+               dev_warn(device, "XXXX Loading firmware from %s\n", path); 
                if (decompress) {
                        dev_dbg(device, "f/w decompressing %s\n",
                                fw_priv->fw_name);
@@ -924,6 +924,10 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
                fw_log_firmware_info(fw, name, device);
        }
 
+       dev_warn(device, "XXXX request-firmware name=%s, ret=%d\n",   name, ret);

        *firmware_p = fw;
        return ret;
 }