Package Base Details: linux-amd

Git Clone URL: https://aur.archlinux.org/linux-amd.git (read-only, click to copy)
Submitter: eggz
Maintainer: eggz (NhaMeh)
Last Packager: eggz
Votes: 13
Popularity: 1.21
First Submitted: 2019-11-10 15:20
Last Updated: 2021-12-01 09:30

Pinned Comments

eggz commented on 2020-10-26 18:15

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.

If you use znver2 based hardware, please use linux-amd-znver2
If you use raven based hardware, please use linux-amd-raven

eggz commented on 2019-11-10 15:23

Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :

[linuxkernels]
Server = http://nhameh.ovh/$repo/$arch
SigLevel = Optional TrustAll

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 ... Next › Last »

traysh commented on 2021-09-02 10:27

I've got a AMD Ryzen 7 4800H with Radeon Graphics. I suppose I should use linux-amd-znver2, is that correct?

eggz commented on 2021-08-25 15:25

Yeah, they are probably good enough on zen 3.

itoffshore commented on 2021-08-25 12:09

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:

  • linux-hardened-cacule
  • linux-cacule-rt
  • linux-xanmod-cacule

The cacule kernels allow AMD optimizations which is probably good enough on Zen 3.

eggz commented on 2021-08-25 07:11

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.

itoffshore commented on 2021-08-25 02:57

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"

eggz commented on 2021-08-22 07:27

in regards to powersaving features this kernel does not offer any special features.

ciupenhauer commented on 2021-08-21 23:11

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?

JP-Ellis commented on 2021-08-18 22:19

@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.

eggz commented on 2021-08-18 21:37

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...

Moo-Crumpus commented on 2021-08-05 12:37

however, it should not pull mkinitcpio