Bug#929583: linux-image-5.0.0-trunk-amd64: Please build with CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ
Package: src:linux
Version: 5.0.2-1~exp1
Severity: severe
Please build Debian kernels with CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ
enabled.
I have a laptop with UEFI Secure Boot support. I dual-boot Windows and
I also want to use Secure Boot to make sure that Debian kernels are
running. Beyond that, I'd like no restrictions on my own ability to
develop kernel modules without having to reboot to disable Secure Boot,
or having to build my own kernels with my own keys and also having to
figure out how to sign and load kernel modules just to fix bugs. (It
also seems dubious to be signing half-finished modules, which haven't
been vetted for security, during the development process.)
Currently, on systems with Secure Boot enabled, it is difficult or
impossible to build and load custom kernel modules without disabling
UEFI Secure Boot entirely.
The ostensible purpose of UEFI Secure boot is to prevent unsigned,
malicious bootloaders from subverting the operating system without the
end-user's awareness. It can also be used by hardware manufacturers to
lock down machines against users who wish to load their own kernel
modules, but that purpose is not compatible with Debian's Social
Contract ("4. Our priorities are our users and free software"), and
Debian should not be complicit in this.
IMO if Debian is shipping Secure Boot-compatibled signed kernels at all,
Debian must also provide end-users with the ability to load their own
kernel-mode code with Secure Boot enabled. shim, which is signed by
Microsoft, already allows users to load keys (and thus execute arbitrary
kernel-mode code) once the user has given their affirmative consent to
do so. Nothing should stop Debian from doing likewise, and that's what
the ALLOW_LOCKDOWN_LIFT_BY_SYSRQ config option does.
The upstream kernel maintainers have expressed opposition to tying UEFI
Secure Boot to lockdown mode in the first place, and much of the the
justification for supporting Secure Boot -> Lockdown in a FOSS kernel at
all has been that this sysrq key combination would be available to
users. Currently, this is not the case in Debian signed kernels.
Since buster reportedly will ship signed kernels, and since I believe
the status quo violates the Social Contract (and that it would be a
shame if buster shipped in a form that allowed Debian-signed kernels to
be used to help hardware manufacturers assert control over end-users
restrict users on their own hardware), I have marked this bug with a
release-critical severity.
-- Package-specific info:
** Version:
Linux version 5.0.0-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-3)) #1 SMP Debian 5.0.2-1~exp1 (2019-03-18)
** Model information
sys_vendor: LENOVO
product_name: 20MUCTO1WW
product_version: ThinkPad A485
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: R0WET48W (1.16 )
board_vendor: LENOVO
board_name: 20MUCTO1WW
board_version: SDK0J40697 WIN
** Loaded modules:
cpuid
ufs
qnx4
hfsplus
hfs
minix
ntfs
msdos
jfs
xfs
dm_snapshot
dm_bufio
cmac
rfcomm
bnep
vmw_vsock_vmci_transport
vsock
vmw_vmci
pci_stub
vboxpci(OE)
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
ctr
ccm
devlink
nf_tables
nfnetlink
squashfs
overlay
cpufreq_userspace
cpufreq_powersave
cpufreq_conservative
edac_mce_amd
kvm_amd
ccp
kvm
binfmt_misc
btusb
btrtl
btbcm
uvcvideo
hid_multitouch
nls_ascii
btintel
nls_cp437
vfat
fat
bluetooth
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
media
drbg
ansi_cprng
ecdh_generic
irqbypass
joydev
efi_pstore
snd_hda_codec_realtek
snd_hda_codec_generic
arc4
snd_hda_codec_hdmi
bfq
efivars
serio_raw
r8822be(C)
snd_hda_intel
tpm_crb
sg
wmi_bmof
snd_hda_codec
k10temp
snd_hda_core
mac80211
snd_hwdep
sp5100_tco
thinkpad_acpi
snd_pcm
nvram
tpm_tis
snd_timer
ledtrig_audio
snd
ipmi_devintf
rtsx_pci_ms
tpm_tis_core
cfg80211
ipmi_msghandler
ucsi_acpi
typec_ucsi
soundcore
memstick
tpm
typec
rfkill
rng_core
ext4
ac
battery
crc16
mbcache
jbd2
crc32c_generic
fscrypto
pcc_cpufreq
evdev
ecb
acpi_cpufreq
loop
cuse
vmwgfx
fuse
parport_pc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
btrfs
zstd_decompress
zstd_compress
algif_skcipher
af_alg
hid_generic
usbhid
hid
dm_crypt
dm_mod
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
raid1
raid0
multipath
linear
md_mod
sd_mod
crct10dif_pclmul
crc32_pclmul
crc32c_intel
rtsx_pci_sdmmc
ghash_clmulni_intel
mmc_core
amdgpu
aesni_intel
chash
gpu_sched
i2c_algo_bit
ahci
ttm
libahci
aes_x86_64
crypto_simd
cryptd
xhci_pci
drm_kms_helper
libata
glue_helper
ehci_pci
xhci_hcd
psmouse
ehci_hcd
drm
scsi_mod
usbcore
i2c_piix4
r8169
realtek
libphy
usb_common
rtsx_pci
wmi
video
i2c_scmi
button
-- System Information:
Debian Release: 10.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.0.0-trunk-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-image-5.0.0-trunk-amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.133
ii kmod 26-1
ii linux-base 4.6
Versions of packages linux-image-5.0.0-trunk-amd64 recommends:
ii apparmor 2.13.2-10
ii firmware-linux-free 3.4
ii irqbalance 1.5.0-4
Versions of packages linux-image-5.0.0-trunk-amd64 suggests:
pn debian-kernel-handbook <none>
ii extlinux 3:6.04~git20190206.bf6db5b4+dfsg1-1
ii grub-efi-amd64 2.02+dfsg1-18
pn linux-doc-5.0 <none>
Versions of packages linux-image-5.0.0-trunk-amd64 is related to:
ii firmware-amd-graphics 20190502-1
pn firmware-atheros <none>
pn firmware-bnx2 <none>
pn firmware-bnx2x <none>
ii firmware-brcm80211 20190502-1
pn firmware-cavium <none>
pn firmware-intel-sound <none>
pn firmware-intelwimax <none>
pn firmware-ipw2x00 <none>
pn firmware-ivtv <none>
pn firmware-iwlwifi <none>
pn firmware-libertas <none>
ii firmware-linux-nonfree 20190502-1
ii firmware-misc-nonfree 20190502-1
pn firmware-myricom <none>
pn firmware-netxen <none>
pn firmware-qlogic <none>
ii firmware-realtek 20190502-1
pn firmware-samsung <none>
pn firmware-siano <none>
pn firmware-ti-connectivity <none>
pn xen-hypervisor <none>
-- no debconf information
Reply to: