the signed template together with the binary package(s) containing the unsigned
files form the input to our secure boot signing service.
the signed template consists of
- files.json (specifying which files are signed how and by which key)
- packaging template used to build the signed package(s)
the signing service
- extracts and checks the signed-template binary package
- extracts the unsigned package(s)
- signs the needed files
- packs up the signatures + the template contained in the signed-template
package into the signed source package
the signed source package can then be built in the regular fashion (in case of
the kernel packages, it will copy the kernel image, modules and some helper
files from the unsigned package, attach the signature created by the signing
service, and re-pack the result as signed-kernel package).
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
it's really not just ZFS and AMDGPU modules, but way more and
generating scary looking messages for these "issues" is just noise
that drown real issues. Disable this for now, maybe in another few
years.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
makes it easier to cherry-pick newer stable release tags, that
sometimes contain new config values one must pick from.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
it's mostly noise for users, and quiet some interpret this as real
problem and report it to us.
Ideally we'd either educate them, or take time ourself, to report this
upstream and see if the situation can be improved overall, but
currently that's not feasible. We should check this out a few releases
down, if the lower hanging fruits got fixed and noise got lower we
could enable it again to catch the more rare cases.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We have a slightly better fix where only a few targeted ZFS module
parts are added to the UBSAN ignore-list, so the rest of the kernel
still gets exposure.
Link: https://github.com/openzfs/zfs/pull/15510
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Following ZFS commit ad9e76765 ("linux: module: weld all but spl.ko
into zfs.ko") we only have two modules to care about.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
when not having installed an intel-microcode version containing the
mitigation, this options disables AVX instructions, which breaks quite
a lot of software (e.g. firefox, electron apps)
Reported-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
this is required for secure boot support.
at build time, an ephemeral key pair will be generated and all built modules
will be signed with it. the private key is discarded, and the public key
embedded in the kernel image for signature validation at module load time.
this change means that every kernel release must be considered an ABI change
from now on, else the signatures of on-disk modules and the signing key
embedded in the running kernel image might not match.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
long overdue, and avoids the issue of the meta packages version going down
after being folded in from the pve-kernel-meta repository.
the ABI needs to be bumped for every published kernel package now that modules
are signed, else the booted kernel image containing the public part of the
ephemeral signing key, and the on-disk (potentially upgraded in-place) signed
module files can disagree, and module loading would fail.
not changed (yet): git repository name, pve-firmware
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
no fun to build the kernel with just a single job at the same time,
which happens e.g., in an sbuild environment.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
but allow discarding BTF information when loading modules, so that upgrades
which are otherwise ABI compatible still work. this allows using BTF
information when matching and available, while degrading gracefully if the
currently running kernel is not identical to the one that module was built for.
in case of a mismatch, the kernel will log a warning when loading the module,
for example:
Jan 30 13:57:58 test kernel: BPF: type_id=184 bits_offset=4096
Jan 30 13:57:58 test kernel: BPF:
Jan 30 13:57:58 test kernel: BPF: Invalid name
Jan 30 13:57:58 test kernel: BPF:
Jan 30 13:57:58 test kernel: failed to validate module [bonding] BTF: -22
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
same info but shorter, avoiding cut-off on `uname -a` output due to
the relatively newly changed and reported "SMP PREEMPT_DYNAMIC" mode.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Useless since 5.5 and will fail build with 5.16+, see upstream linux
commit 7ecaf069da52 and 4fbce819337a for some details
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we cannot make this a built-in easily due to kconfig dependency
resolution.
We'll handle the availability in initrd with a initramfs modules.d
snippet shipped by the meta package,
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Debian did so since 5.10~rc7-1~exp1 and ubuntu only disabled it due
some concerns about "high" memory usage on many-core systems[0], high
is to be seen relative here as its 26 MiB on 208 cores[1] and only
matters for ubuntu as due to their snaps they may have a lot of
active squashfs mounts.
Proxmox projects do not use snaps, or other things that uses squashfs
instances a tall besides the installer. While some users may use a
few it is unlikely to cause much problems (a few 100 MiB should not
be a big problem on a server with hundreds of online cores.
Any how, to speed up decompression in our installer and use a similar
setting as Debian, the distro we're most similar too, enable this
Kconfig knob.
[0]: https://bugs.launchpad.net/snappy/+bug/1636847
[1]: https://bugs.launchpad.net/snappy/+bug/1636847/comments/21
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
sometimes the build would fail with
cp: cannot stat 'ubuntu-hirsute/.tmp_1987275': No such file or directory
make[1]: *** [debian/rules:181: .headers_prepare_mark] Error 1
make[1]: Leaving directory '/home/fgruenbichler/pve-kernel/build'
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2
make: *** [Makefile:58: pve-kernel-5.11.21-1-pve_5.11.21-1_amd64.deb] Error 2
if copying was slow enough.
so let's do the copying first, then do the rest in parallel without
needing to worry about side-effects.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
and put them into a new -dbgsym package for usage with
crash/kdump-tools/...
fixes#3465, and now allows to do the following (after installing
and configuring kdump-tools to collect kernel crash dumps) when the
system crashes:
$ apt install pve-kernel-5.11.21-1-dbgsym
$ crash /usr/lib/debug/boot/vmlinux-5.11.21-1-pve /var/crash/202106151236/dump.202106151236
crash 7.2.9
Copyright (C) 2002-2020 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
WARNING: kernel relocated [812MB]: patching 136336 gdb minimal_symbol values
KERNEL: /usr/lib/debug/boot/vmlinux-5.11.21-1-pve
DUMPFILE: /var/crash/202106151236/dump.202106151236 [PARTIAL DUMP]
CPUS: 4
DATE: Tue Jun 15 12:36:38 CEST 2021
UPTIME: 00:06:21
LOAD AVERAGE: 0.04, 0.11, 0.08
TASKS: 272
NODENAME: test
RELEASE: 5.11.21-1-pve
VERSION: #1 SMP PVE 5.11.21-1 (Tue, 01 Jun 2021 16:38:57 +0200)
MACHINE: x86_64 (3696 Mhz)
MEMORY: 8 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
PID: 3167
COMMAND: "bash"
TASK: ffff9220c8f5be00 [THREAD_INFO: ffff9220c8f5be00]
CPU: 3
STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 3167 TASK: ffff9220c8f5be00 CPU: 3 COMMAND: "bash"
#0 [ffffa24ec0bfbc80] machine_kexec at ffffffffb3c751f3
#1 [ffffa24ec0bfbce0] __crash_kexec at ffffffffb3d61092
#2 [ffffa24ec0bfbdb0] panic at ffffffffb47b769d
#3 [ffffa24ec0bfbe30] sysrq_handle_crash at ffffffffb434da4a
#4 [ffffa24ec0bfbe40] __handle_sysrq.cold at ffffffffb47e2cdc
#5 [ffffa24ec0bfbe78] write_sysrq_trigger at ffffffffb434e3f8
#6 [ffffa24ec0bfbe90] proc_reg_write at ffffffffb3fc09ea
#7 [ffffa24ec0bfbeb0] vfs_write at ffffffffb3f143b6
#8 [ffffa24ec0bfbee8] ksys_write at ffffffffb3f16b97
#9 [ffffa24ec0bfbf28] __x64_sys_write at ffffffffb3f16c2a
#10 [ffffa24ec0bfbf38] do_syscall_64 at ffffffffb480e868
#11 [ffffa24ec0bfbf50] entry_SYSCALL_64_after_hwframe at ffffffffb4a0008c
RIP: 00007f367f7baf33 RSP: 00007ffe6175dc98 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f367f7baf33
RDX: 0000000000000002 RSI: 0000560510e640b0 RDI: 0000000000000001
RBP: 0000560510e640b0 R8: 000000000000000a R9: 0000000000000001
R10: 0000560510e5f800 R11: 0000000000000246 R12: 0000000000000002
R13: 00007f367f88b6a0 R14: 0000000000000002 R15: 00007f367f88b8a0
ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b
as well as lots of other fun things (see 'help' after opening a crash dump).
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
The prepare/compile/install targets feel a bit mixed, so it's not
100% clear where this should happen.
But as the `.headers_compile_mark` already triggers various kernel
build targets with a correct kconfig setup, it is a good fit to add
the modules_prepare step (which is recommended to use when preparing
a out-of-three (OOT) module build environment like dkms expects)
there. As we can only copy (= install) the `scripts` directory
afterwards it follows that it needs to be moved afterwards. Moving
installing the `include` directory there is not really necessary but
it feels like a better place than the _prepare_ target and safes a
extra line, so move that over too.
In terms of actual changes to the built header package we get
additionally the, now generated, module.lds file.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Those files are generated by the `if_changed` macro from
scripts/Kbuild.include and are not really useful or interesting for
being shipped in the header packages and other distros (checked
Debian and Ubuntu) do not seem to ship those at all..
So, lets prune them to reduce shipped files dramatically, without
losing, well, anything.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we do not use module signing currently.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
(cherry picked from commit 77470417db)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
since it prevents boot with our current way of building ZFS modules in
case a system is booted with secureboot enabled.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
This was long overdue, allows to access the full feature set of our
kernel for some tools using the Linux API directly.
Packaging mostly taken from Debian[0]
[0]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/4.19.118-2/debian/rules.real#L367
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Reviewed-By: Fabian Grünbichler <f.gruenbichler@proxmox.com>
The PC speaker (beeper) can only be managed by one module, and there
are two which could do so. The very basic INPUT_PCSPKR, and the more
advanced SND_PCSP which allows it to be used as primitive ALSA
soundcard, which for Proxmox Server projects, and all modern
workstations is not much of use.
As they both were aliased to the "pcspkr" module name, and used the
same internal driver name (being a replacment of the other), one
would get the following error message when both are loaded:
"Error: Driver 'pcspkr' is already registered, aborting..."
in the kernel log. This happens as by default both are tried to get
loaded. We do not want the more complex ALSA one, so disable that.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Allows to mount VFAT devices even if the currently running kernel was
removed before any VFAT, or other FS using the default Native
Language Support module was mounted during the current uptime.
This then could break updating the ESP partitions, which are mounted
with VFAT in a postrm triggered step - so at a time where the current
/lib/modules/... was already removed, and so the NLS could not get
loaded.
While there are a lot of different NLS, our kernel config has:
> CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
So compile that module as built-in.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the current OOT are not compatible with 5.0 and we want to obsolete
them anyway sooner or later
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
no problems had been reported with it, in contrary to igb and e1000e
so use the newer and better supported in tree driver.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
There where just to much issues with the 4.15 in tree drivers for our
users [1]. The updated igb and ixgbe drivers are compatible with
4.15, the e1000e driver needed to be ported to the new internal
kernel timer API, which is pretty straight forward.
[1]: https://forum.proxmox.com/threads/4-15-based-test-kernel-for-pve-5-x-available.42097/page-5
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
