NOTE: Refer to Boot Loader for how to add the parameter to your boot configuration.
To verify that kernel mode setting is enabled: ~~~bash cat /sys/module/nvidia_drm/parameters/modeset ~~~ `Y` means Kernel Mode Setting was enabled on boot. `N` means Kernel Mode Setting was **not** enabled on boot. # Sound For audio handling on Linux, PipeWire is the currently recommended framework. PipeWire is a server and user space API that provides a platform to handle multimedia pipelines. It is a modern, low-latency audio and video server designed to work with the latest audio use cases and handle professional audio interfaces and applications. PipeWire was created as a replacement for both the PulseAudio sound server and the Jack Audio Connection Kit (JACK) server. It provides a unified interface for handling video and audio streams and is intended to be flexible and extensible, allowing it to address not only audio but other multimedia tasks as well, such as video conferencing, screen capture, and other multimedia applications. It can also work with different hardware devices, including webcams, microphones, and professional audio devices. Additionally, it integrates better with the security models of Flatpak and Wayland. It does so via sandboxing processes from one another, preventing an application from snooping on other applications' audio streams. Before allowing an application to record audio or sharing the screen(e.g. in a browser over WebRTC) it will ask the user for permission to do so. PipeWire implements no connection logic internally, that is the responsibility of a program called a session manager. It watches for new streams and connects them to the appropriate output device or application. There are two session managers to choose from: * **PipeWire Media Session:** A very simple session manager that caters to some basic desktop use cases. It was mostly implemented for testing and as an example for building new session managers. * **WirePlumber:** A more powerful manager and the current recommendation. It is based on a modular design, with Lua plugins that implement the actual management functionality. WirePlumber is the recommended choice, as it is better maintained, receives regular updates and is more feature-rich. ## Installation The most basic PipeWire setup includes the following packages:NOTE: PipeWire handles Bluetooth audio devices if the pipewire-audio package is installed.
TIP: firewalld has a preset for RTSP. Make sure to apply the firewall changes permanently.
WARNING: When using this method on your root volume, there are a few caveats to be aware of.
Provided the PCR slots you chose to seal against are considered valid by the system, the TPM will automatically unlock the LUKS volume at boot without the need to enter a password.
However, this also means that in case of theft, the data is no longer protected by the encryption. Furthermore, this also makes you more vulnerable to cold boot attacks, since the computer just has to be booted up to gain access to the decrypted data, without even the need to tamper with the device in order to crack the encryption.
It is therefore strongly recommended to at least pass the --tpm2-with-pin=yes option to systemd-cryptenroll to still have a mechanism for user verification (available with systemd version 251).
TIP: If there are no devices listed, make sure the TPM is enabled in your device's firmware. Devices from 2016 onwards usually have a TPM 2.0, as it is a requirement from Microsoft for Windows 10 certification for hardware manufacturers.
~~~bash systemd-cryptenroll --tpm2-device=list ~~~ To enroll a new TPM-based key into a LUKS slot specify the TPM device to generate the key from and the PCRs to seal against, followed by the LUKS volume to save a new slot to (using `/dev/nvme0n1p2` as an example):ATTENTION: The more PCRs you bind to, the more hardened your setup becomes. But at the same time you can also end up with a less flexible setup — e.g. binding your TPM LUKS key to PCRs 8, 9 and/or 11 harden your system against attempts to boot a kernel image which's hashes aren't measured into these PCRs but the moment your kernel changes (i.e. you update your kernel, change initrd generation, etc.) the PCRs stop validating and trigger a passphrase or recovery key prompt!
TIP: If your device only has one TPM (which is usually the case) you can supply --tpm2-device=auto to use the only device available.
TIP: Again, if your device only has one TPM you can supply tpm2-device=auto to use the only device available.
ATTENTION: If you want to use tpm2-totp in conjunction with Plymouth you will have to use the tpm2-totp-git package from the AUR, since Arch Linux does not officially support Plymouth and the Repo package lacks the initcpio hooks needed for Plymouth support.
Use the plymouth-tpm2-totp hook in conjunction with the encrypt hook, or sd-plymouth-tpm2-totp in conjunction with the sd-encrypt hook.
NOTE: Generate keys as a regular user!
To start using a U2F key for system-level authentication, keys need to be created first. The default directory these keys will usually be looked for is at `~/.config/Yubico` (since the `pam-u2f` package is developed by Yubico for use with their Yubikeys, but it works with other keys as well). Create the directory under your home directory: ~~~bash mkdir ~/.config/Yubico ~~~ The `pam-u2f` package comes with a utility to create keys from the USB device. Create new keys with `pamu2fcfg`:WARNING: This takes your machine's current host name and assumes it is not re-assigned on network changes! Changing your machine's host name might render the key unable to authenticate you until your machine returns to the original host name.
NOTE: Keep an eye on your hardware security token, as it might silently indicate it is waiting on user interaction to continue.
~~~bash pamu2fcfg -o pam://$HOST -i pam://$HOST > ~/.config/Yubico/u2f_keys ~~~ ## System-wide U2F promptsATTENTION: A potentially undesirable side effect of this method is that any keychains that use the user password to unlock, such as the login keychain in GNOME or KDE, will immediately request the password after login. Since this allows passwordless logins, the user password for unlocking will not be passed on to the secrets provider. If you depend on automatic unlocking of the login keychain, e.g. for SSH key passphrases or Wi-Fi passwords, see one of the other methods below.
To use your physical security key system-wide and not just for specific use-cases, add the following line **before** the first `auth` line in `/etc/pam.d/system-auth`:NOTE: Be sure to replace hostname with the actual host name of your machine!
WARNING: Changes to PAM configuration files apply immediately! Before making any changes to your configuration, start a separate shell with root permissions (e.g. sudo -s). This way you can revert any changes if something goes wrong.
NOTE: Be sure to replace hostname with the actual host name of your machine!
NOTE: Be sure to replace hostname with the actual host name of your machine!
NOTE: Be sure to replace hostname with the actual host name of your machine!
WARNING: If you lose your key you will also lose your ability to authenticate and log in to your user account. You could theoretically use sufficient instead of required but this would render the security benefits of this endeavour pointless, as the password would still be enough to gain access to your account.
ATTENTION: Make sure to pass the device node of your actual LUKS container!
~~~bash systemd-cryptenroll --fido2-device=auto /dev/nvme0n1p2 ~~~ To make systemd use the FIDO2 key for unlocking during boot, add the following option to your `rd.luks.options` list of options: ~~~ rd.luks.options=fido2-device=auto ~~~ Alternatively, if you do not want to pass this as a kernel command line option, add the option to your `/etc/crypttab.initramfs` and regenerate your initramfs after you've made changes: ~~~ #