| Git Clone URL: | https://aur.archlinux.org/linux-amd.git (read-only, click to copy) |
|---|---|
| Package Base: | linux-amd |
| Description: | Headers and scripts for building modules for the linux-amd package |
| Upstream URL: | https://www.kernel.org/ |
| Licenses: | GPL-2.0-only |
| Submitter: | None |
| Maintainer: | archdevlab |
| Last Packager: | archdevlab |
| Votes: | 33 |
| Popularity: | 0.21 |
| First Submitted: | 2019-11-10 15:20 (UTC) |
| Last Updated: | 2024-08-21 00:22 (UTC) |
The performance impact is zero for signed modules once booted & enforcing them is a kernel boot option choice by the user. They are implemented with no issues on the following performance kernels:
The cacule kernels allow AMD optimizations which is probably good enough on Zen 3.
For the same reason I disabled audit on these kernels, Hardening security is not a prio on this kernel, performance is. Signing all drivers by default and then not forcing a lockdown policy seems a pointless exercise to me (heck, signing modules in general is a bit too paranoid for my taste anyway) -- It would take away from the performance profile we have been building up.
If you want a hardened kernel, this is not the one.
Can you enable configuration please so that for example /usr/lib/modules/5.13.12-AMD/build/scripts/sign-file is created ? (so kernel modules can be cryptographically signed):
At the moment it is not enabled with /usr/lib/modules/5.13.12-AMD/build/scripts/sign-file.c showing in the package.
Officially supported kernels are configured with:
CONFIG_MODULE_SIG_FORMAT=y
CONFIG_MODULE_SIG=y
# CONFIG_MODULE_SIG_FORCE is not set
CONFIG_MODULE_SIG_ALL=y
# CONFIG_MODULE_SIG_SHA1 is not set
# CONFIG_MODULE_SIG_SHA224 is not set
# CONFIG_MODULE_SIG_SHA256 is not set
# CONFIG_MODULE_SIG_SHA384 is not set
CONFIG_MODULE_SIG_SHA512=y
CONFIG_MODULE_SIG_HASH="sha512"
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
in regards to powersaving features this kernel does not offer any special features.
Are there any notes about power saving regarding this kernel? Is it optimized to be more power hungry than default or does it not have any impact?
@eggz Thanks, the addition of fscrypt is much appreciated.
I'm not sure why there is a concern regarding performance hit as it should only apply to those people who wish to use it, and the performance degradation would only appear when it is being used. Lastly, although LUKS and fscrypt both offer encryption, they have two very different approaches and definitely are not interchangeable.
I added fscrypt support due to popular demand, but I have my reservations over its security and performance. Luks seems to be a much better way to do this...
however, it should not pull mkinitcpio
@Moo, no swearing and slander please. You have been warned.
Why does this kernel pull mkinitcpio? Think about booster and dracut, it should the users choice, not the kernels.
Pinned Comments
archdevlab commented on 2024-08-15 03:38 (UTC)
Hi
I have adopted this package and have updated it!
Thanks!
<deleted-account> commented on 2023-05-04 16:38 (UTC)
GCC13.1 is mainlined in arch, so this means znver4 support can kick off on this kernel. The graysky compile patches have been updated too.
This kernel now natively supports the znver4 arch, but this kernel will most likely keep working on all AMD ryzen hardware. It's better to be able to address certain small perks or issues per architecture now and in the future.
<deleted-account> commented on 2020-10-26 18:15 (UTC)
GCC11.1 is mainlined in arch, so this means znver3 support can kick off on this kernel. The graysky compile patches have been updated too.
This kernel now natively supports the znver3 arch, but this kernel will most likely keep working on all AMD ryzen hardware. It's better to be able to address certain small perks or issues per architecture now and in the future.
<deleted-account> commented on 2019-11-10 15:23 (UTC)
Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :