https://wiki.alpinelinux.org/w/api.php?action=feedcontributions&user=Orson+Teodoro&feedformat=atomAlpine Linux - User contributions [en]2024-03-29T10:04:01ZUser contributionsMediaWiki 1.40.0https://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15216Setting up a laptop2018-03-18T17:55:40Z<p>Orson Teodoro: /* Guide features */ clarify</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical object (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical object.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
If you use a USB keyboard, you will unlock the encrypted devices in early userspace. You will need to either compile the USB keyboard drivers in the kernel or you need to add additional modules when generating the mkinitfs. You will need the hid, hid-generic, ehci-hcd, uhci-hcd, usbcore driver and add those paths in a customized <code>/etc/mkinitfs/features.d/usb-keyboard.modules</code>. It should be separate from usb.modules because apk updates may overwrite it. Use the <code>lsmod</code> utility from the kmod package to find what drivers your USB keyboard uses.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows? From research from cold boot attack, the data can actually stay in memory in minutes, just enough time for a hacker to copy the contents of the memory to a USB thumb drive.<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory if you enable it (but not enabled by default in the Alpine hardened kernel) when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS or use Intel TXT or TPM which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition an USB thumb drive containing an encryption key retriever bypassing the operating system.[https://youtu.be/XfUlRsE3ymQ]<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15215Setting up a laptop2018-03-18T17:55:19Z<p>Orson Teodoro: /* Hacking mkinitfs to support cryptsetup with GPG keys */ clarify</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical object.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
If you use a USB keyboard, you will unlock the encrypted devices in early userspace. You will need to either compile the USB keyboard drivers in the kernel or you need to add additional modules when generating the mkinitfs. You will need the hid, hid-generic, ehci-hcd, uhci-hcd, usbcore driver and add those paths in a customized <code>/etc/mkinitfs/features.d/usb-keyboard.modules</code>. It should be separate from usb.modules because apk updates may overwrite it. Use the <code>lsmod</code> utility from the kmod package to find what drivers your USB keyboard uses.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows? From research from cold boot attack, the data can actually stay in memory in minutes, just enough time for a hacker to copy the contents of the memory to a USB thumb drive.<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory if you enable it (but not enabled by default in the Alpine hardened kernel) when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS or use Intel TXT or TPM which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition an USB thumb drive containing an encryption key retriever bypassing the operating system.[https://youtu.be/XfUlRsE3ymQ]<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15214Setting up a laptop2018-03-18T17:54:11Z<p>Orson Teodoro: /* Hacking mkinitfs to support cryptsetup with GPG keys */ fix grammar</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
If you use a USB keyboard, you will unlock the encrypted devices in early userspace. You will need to either compile the USB keyboard drivers in the kernel or you need to add additional modules when generating the mkinitfs. You will need the hid, hid-generic, ehci-hcd, uhci-hcd, usbcore driver and add those paths in a customized <code>/etc/mkinitfs/features.d/usb-keyboard.modules</code>. It should be separate from usb.modules because apk updates may overwrite it. Use the <code>lsmod</code> utility from the kmod package to find what drivers your USB keyboard uses.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows? From research from cold boot attack, the data can actually stay in memory in minutes, just enough time for a hacker to copy the contents of the memory to a USB thumb drive.<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory if you enable it (but not enabled by default in the Alpine hardened kernel) when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS or use Intel TXT or TPM which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition an USB thumb drive containing an encryption key retriever bypassing the operating system.[https://youtu.be/XfUlRsE3ymQ]<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15212Custom Kernel2018-03-18T00:58:05Z<p>Orson Teodoro: /* Sanitize memory of private sensitive information */ rearrange and integrate</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
You should disable modules to increase security. By default, Alpine will install modules but not disable most of them. Disabling modules will reduce an DMA attack but not eliminate it completely. If you have a newer processor with VT-d, you can mitigate as long as you:<br />
<br />
Leave CONFIG_INTEL_IOMMU_DEFAULT_ON=y or pass intel_iommu=on as a kernel parameter and disable kernel logging so the attacker doesn't gain DMAR address information through dmesg.[http://blog.frizk.net/2016/11/disable-virtualization-based-security.html] Also remove references to the kernel version to calculate the IOMMU addresses.[https://link.springer.com/content/pdf/10.1186/s13173-017-0066-7.pdf]<br />
<br />
To increase the security of the boot process, if you have a TPM, you could set CONFIG_INTEL_TXT=y (Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)) (which is not enabled in the hardened kernel by default), then you would need the SINIT module (provided only by Intel)[https://software.intel.com/en-us/articles/intel-trusted-execution-technology], a possibly compiled TrustedGrub2[https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2], trousers[https://sourceforge.net/projects/trousers/?source=navbar], tboot[https://sourceforge.net/projects/tboot/]. These packages are not in aports and it is unknown if these tools work on musl. It's not recommended for Edge. Also, there would be trigger packages to generate hashes for the kernel and the mkinitfs updates.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
=== Sanitize memory of private sensitive information ===<br />
<br />
To increase privacy and minimize data theft of sensitive information,[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory (full description of the feature on WikiBooks)] you may want to enable the following:<br />
<br />
(Available only in the hardened kernel and not enabled by default in the Alpine hardened kernel.)<br />
<br />
Security options<br />
Grsecurity<br />
PaX<br />
Miscellaneous hardening features<br />
[*] Sanitize all freed memory<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15211Custom Kernel2018-03-18T00:55:07Z<p>Orson Teodoro: /* Sanitize memory */ rename</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
You should disable modules to increase security. By default, Alpine will install modules but not disable most of them. Disabling modules will reduce an DMA attack but not eliminate it completely. If you have a newer processor with VT-d, you can mitigate as long as you:<br />
<br />
Leave CONFIG_INTEL_IOMMU_DEFAULT_ON=y or pass intel_iommu=on as a kernel parameter and disable kernel logging so the attacker doesn't gain DMAR address information through dmesg.[http://blog.frizk.net/2016/11/disable-virtualization-based-security.html] Also remove references to the kernel version to calculate the IOMMU addresses.[https://link.springer.com/content/pdf/10.1186/s13173-017-0066-7.pdf]<br />
<br />
To increase the security of the boot process, if you have a TPM, you could set CONFIG_INTEL_TXT=y (Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)) (which is not enabled in the hardened kernel by default), then you would need the SINIT module (provided only by Intel)[https://software.intel.com/en-us/articles/intel-trusted-execution-technology], a possibly compiled TrustedGrub2[https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2], trousers[https://sourceforge.net/projects/trousers/?source=navbar], tboot[https://sourceforge.net/projects/tboot/]. These packages are not in aports and it is unknown if these tools work on musl. It's not recommended for Edge. Also, there would be trigger packages to generate hashes for the kernel and the mkinitfs updates.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
=== Sanitize memory of private sensitive information ===<br />
<br />
To increase privacy and minimize data theft of sensitive information,[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory (full description of the feature on WikiBooks)] you may want to enable the following. This feature is not enabled by default in the Alpine hardened kernel.<br />
<br />
(Available only in the hardened kernel)<br />
<br />
Security options<br />
Grsecurity<br />
PaX<br />
Miscellaneous hardening features<br />
[*] Sanitize all freed memory<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15210Custom Kernel2018-03-18T00:54:15Z<p>Orson Teodoro: /* Sanitize memory */ put link description</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
You should disable modules to increase security. By default, Alpine will install modules but not disable most of them. Disabling modules will reduce an DMA attack but not eliminate it completely. If you have a newer processor with VT-d, you can mitigate as long as you:<br />
<br />
Leave CONFIG_INTEL_IOMMU_DEFAULT_ON=y or pass intel_iommu=on as a kernel parameter and disable kernel logging so the attacker doesn't gain DMAR address information through dmesg.[http://blog.frizk.net/2016/11/disable-virtualization-based-security.html] Also remove references to the kernel version to calculate the IOMMU addresses.[https://link.springer.com/content/pdf/10.1186/s13173-017-0066-7.pdf]<br />
<br />
To increase the security of the boot process, if you have a TPM, you could set CONFIG_INTEL_TXT=y (Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)) (which is not enabled in the hardened kernel by default), then you would need the SINIT module (provided only by Intel)[https://software.intel.com/en-us/articles/intel-trusted-execution-technology], a possibly compiled TrustedGrub2[https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2], trousers[https://sourceforge.net/projects/trousers/?source=navbar], tboot[https://sourceforge.net/projects/tboot/]. These packages are not in aports and it is unknown if these tools work on musl. It's not recommended for Edge. Also, there would be trigger packages to generate hashes for the kernel and the mkinitfs updates.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
=== Sanitize memory ===<br />
<br />
To increase privacy and minimize data theft of sensitive information,[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory (full description of the feature on WikiBooks)] you may want to enable the following. This feature is not enabled by default in the Alpine hardened kernel.<br />
<br />
(Available only in the hardened kernel)<br />
<br />
Security options<br />
Grsecurity<br />
PaX<br />
Miscellaneous hardening features<br />
[*] Sanitize all freed memory<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15209Custom Kernel2018-03-18T00:53:27Z<p>Orson Teodoro: /* Sanitize memory = */ fix header markup</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
You should disable modules to increase security. By default, Alpine will install modules but not disable most of them. Disabling modules will reduce an DMA attack but not eliminate it completely. If you have a newer processor with VT-d, you can mitigate as long as you:<br />
<br />
Leave CONFIG_INTEL_IOMMU_DEFAULT_ON=y or pass intel_iommu=on as a kernel parameter and disable kernel logging so the attacker doesn't gain DMAR address information through dmesg.[http://blog.frizk.net/2016/11/disable-virtualization-based-security.html] Also remove references to the kernel version to calculate the IOMMU addresses.[https://link.springer.com/content/pdf/10.1186/s13173-017-0066-7.pdf]<br />
<br />
To increase the security of the boot process, if you have a TPM, you could set CONFIG_INTEL_TXT=y (Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)) (which is not enabled in the hardened kernel by default), then you would need the SINIT module (provided only by Intel)[https://software.intel.com/en-us/articles/intel-trusted-execution-technology], a possibly compiled TrustedGrub2[https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2], trousers[https://sourceforge.net/projects/trousers/?source=navbar], tboot[https://sourceforge.net/projects/tboot/]. These packages are not in aports and it is unknown if these tools work on musl. It's not recommended for Edge. Also, there would be trigger packages to generate hashes for the kernel and the mkinitfs updates.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
=== Sanitize memory ===<br />
<br />
To increase privacy and minimize data theft of sensitive information,[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory] you may want to enable the following. This feature is not enabled by default in the Alpine hardened kernel.<br />
<br />
(Available only in the hardened kernel)<br />
<br />
Security options<br />
Grsecurity<br />
PaX<br />
Miscellaneous hardening features<br />
[*] Sanitize all freed memory<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15208Custom Kernel2018-03-18T00:52:58Z<p>Orson Teodoro: /* Configuring kernel */ put sanitize memory section</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
You should disable modules to increase security. By default, Alpine will install modules but not disable most of them. Disabling modules will reduce an DMA attack but not eliminate it completely. If you have a newer processor with VT-d, you can mitigate as long as you:<br />
<br />
Leave CONFIG_INTEL_IOMMU_DEFAULT_ON=y or pass intel_iommu=on as a kernel parameter and disable kernel logging so the attacker doesn't gain DMAR address information through dmesg.[http://blog.frizk.net/2016/11/disable-virtualization-based-security.html] Also remove references to the kernel version to calculate the IOMMU addresses.[https://link.springer.com/content/pdf/10.1186/s13173-017-0066-7.pdf]<br />
<br />
To increase the security of the boot process, if you have a TPM, you could set CONFIG_INTEL_TXT=y (Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)) (which is not enabled in the hardened kernel by default), then you would need the SINIT module (provided only by Intel)[https://software.intel.com/en-us/articles/intel-trusted-execution-technology], a possibly compiled TrustedGrub2[https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2], trousers[https://sourceforge.net/projects/trousers/?source=navbar], tboot[https://sourceforge.net/projects/tboot/]. These packages are not in aports and it is unknown if these tools work on musl. It's not recommended for Edge. Also, there would be trigger packages to generate hashes for the kernel and the mkinitfs updates.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
=== Sanitize memory ====<br />
<br />
To increase privacy and minimize data theft of sensitive information,[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory] you may want to enable the following. This feature is not enabled by default in the Alpine hardened kernel.<br />
<br />
(Available only in the hardened kernel)<br />
<br />
Security options<br />
Grsecurity<br />
PaX<br />
Miscellaneous hardening features<br />
[*] Sanitize all freed memory<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15207Setting up a laptop2018-03-18T00:44:36Z<p>Orson Teodoro: /* secure-delete */ mention memory sanitation is not enabled by default in the hardened kernel</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
If you use a USB keyboard you will unlock the encrypted devices in early userspace, you will need to either compile the USB keyboard drivers in the kernel or you need to add additional modules when generating the mkinitfs. You will need the hid, hid-generic, ehci-hcd, uhci-hcd, usbcore driver and add those paths in a customized <code>/etc/mkinitfs/features.d/usb-keyboard.modules</code>. It should be separate from usb.modules because apk updates may overwrite it. Use the <code>lsmod</code> utility from the kmod package to find what drivers your USB keyboard uses.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows? From research from cold boot attack, the data can actually stay in memory in minutes, just enough time for a hacker to copy the contents of the memory to a USB thumb drive.<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory if you enable it (but not enabled by default in the Alpine hardened kernel) when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS or use Intel TXT or TPM which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition an USB thumb drive containing an encryption key retriever bypassing the operating system.[https://youtu.be/XfUlRsE3ymQ]<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15206Setting up a laptop2018-03-18T00:40:07Z<p>Orson Teodoro: /* secure-delete */ tell how long the data will stay in memory</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
If you use a USB keyboard you will unlock the encrypted devices in early userspace, you will need to either compile the USB keyboard drivers in the kernel or you need to add additional modules when generating the mkinitfs. You will need the hid, hid-generic, ehci-hcd, uhci-hcd, usbcore driver and add those paths in a customized <code>/etc/mkinitfs/features.d/usb-keyboard.modules</code>. It should be separate from usb.modules because apk updates may overwrite it. Use the <code>lsmod</code> utility from the kmod package to find what drivers your USB keyboard uses.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows? From research from cold boot attack, the data can actually stay in memory in minutes, just enough time for a hacker to copy the contents of the memory to a USB thumb drive.<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS or use Intel TXT or TPM which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition an USB thumb drive containing an encryption key retriever bypassing the operating system.[https://youtu.be/XfUlRsE3ymQ]<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15205Setting up a laptop2018-03-18T00:32:41Z<p>Orson Teodoro: /* Important notes */ spelling</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
If you use a USB keyboard you will unlock the encrypted devices in early userspace, you will need to either compile the USB keyboard drivers in the kernel or you need to add additional modules when generating the mkinitfs. You will need the hid, hid-generic, ehci-hcd, uhci-hcd, usbcore driver and add those paths in a customized <code>/etc/mkinitfs/features.d/usb-keyboard.modules</code>. It should be separate from usb.modules because apk updates may overwrite it. Use the <code>lsmod</code> utility from the kmod package to find what drivers your USB keyboard uses.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS or use Intel TXT or TPM which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition an USB thumb drive containing an encryption key retriever bypassing the operating system.[https://youtu.be/XfUlRsE3ymQ]<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15204Setting up a laptop2018-03-18T00:31:56Z<p>Orson Teodoro: /* Important notes */ mention TXT and TPM</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
If you use a USB keyboard you will unlock the encrypted devices in early userspace, you will need to either compile the USB keyboard drivers in the kernel or you need to add additional modules when generating the mkinitfs. You will need the hid, hid-generic, ehci-hcd, uhci-hcd, usbcore driver and add those paths in a customized <code>/etc/mkinitfs/features.d/usb-keyboard.modules</code>. It should be separate from usb.modules because apk updates may overwrite it. Use the <code>lsmod</code> utility from the kmod package to find what drivers your USB keyboard uses.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS or use Intel TXT or TMP which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition an USB thumb drive containing an encryption key retriever bypassing the operating system.[https://youtu.be/XfUlRsE3ymQ]<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15203Setting up a laptop2018-03-18T00:21:49Z<p>Orson Teodoro: /* Hacking mkinitfs to support cryptsetup with GPG keys */ mention early userspace and adding kernel drivers for USB keyboard</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
If you use a USB keyboard you will unlock the encrypted devices in early userspace, you will need to either compile the USB keyboard drivers in the kernel or you need to add additional modules when generating the mkinitfs. You will need the hid, hid-generic, ehci-hcd, uhci-hcd, usbcore driver and add those paths in a customized <code>/etc/mkinitfs/features.d/usb-keyboard.modules</code>. It should be separate from usb.modules because apk updates may overwrite it. Use the <code>lsmod</code> utility from the kmod package to find what drivers your USB keyboard uses.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition an USB thumb drive containing an encryption key retriever bypassing the operating system.[https://youtu.be/XfUlRsE3ymQ]<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15202Custom Kernel2018-03-17T18:21:51Z<p>Orson Teodoro: /* But why? */ fix grammar and put friendly description for feature</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
You should disable modules to increase security. By default, Alpine will install modules but not disable most of them. Disabling modules will reduce an DMA attack but not eliminate it completely. If you have a newer processor with VT-d, you can mitigate as long as you:<br />
<br />
Leave CONFIG_INTEL_IOMMU_DEFAULT_ON=y or pass intel_iommu=on as a kernel parameter and disable kernel logging so the attacker doesn't gain DMAR address information through dmesg.[http://blog.frizk.net/2016/11/disable-virtualization-based-security.html] Also remove references to the kernel version to calculate the IOMMU addresses.[https://link.springer.com/content/pdf/10.1186/s13173-017-0066-7.pdf]<br />
<br />
To increase the security of the boot process, if you have a TPM, you could set CONFIG_INTEL_TXT=y (Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)) (which is not enabled in the hardened kernel by default), then you would need the SINIT module (provided only by Intel)[https://software.intel.com/en-us/articles/intel-trusted-execution-technology], a possibly compiled TrustedGrub2[https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2], trousers[https://sourceforge.net/projects/trousers/?source=navbar], tboot[https://sourceforge.net/projects/tboot/]. These packages are not in aports and it is unknown if these tools work on musl. It's not recommended for Edge. Also, there would be trigger packages to generate hashes for the kernel and the mkinitfs updates.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15201Custom Kernel2018-03-17T08:03:34Z<p>Orson Teodoro: /* But why? */ put link to SINIT modules</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
You should disable modules to increase security. By default, Alpine will install modules but not disable most of them. Disabling modules will reduce an DMA attack but not eliminate it completely. If you have a newer processor with VT-d, you can mitigate as long as you:<br />
<br />
Leave CONFIG_INTEL_IOMMU_DEFAULT_ON=y or pass intel_iommu=on as a kernel parameter and disable kernel logging so the attacker doesn't gain DMAR address information through dmesg.[http://blog.frizk.net/2016/11/disable-virtualization-based-security.html] Also remove references to the kernel version to calculate the IOMMU addresses.[https://link.springer.com/content/pdf/10.1186/s13173-017-0066-7.pdf]<br />
<br />
To increase the security of the boot process if you have a TPM, you could set CONFIG_INTEL_TXT=y (which is not enabled in the hardened kernel by default) then you would need the SINIT module (provided only by Intel)[https://software.intel.com/en-us/articles/intel-trusted-execution-technology], a possibly compiled TrustedGrub2[https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2], trousers[https://sourceforge.net/projects/trousers/?source=navbar], tboot[https://sourceforge.net/projects/tboot/]. These packages are not in aports and it is unknown if these tools work on musl. It's not recommended for Edge. Also, there would be trigger packages to generate hashes for the kernel and the mkinitfs updates.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15200Custom Kernel2018-03-17T07:47:17Z<p>Orson Teodoro: /* But why? */ clarify</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
You should disable modules to increase security. By default, Alpine will install modules but not disable most of them. Disabling modules will reduce an DMA attack but not eliminate it completely. If you have a newer processor with VT-d, you can mitigate as long as you:<br />
<br />
Leave CONFIG_INTEL_IOMMU_DEFAULT_ON=y or pass intel_iommu=on as a kernel parameter and disable kernel logging so the attacker doesn't gain DMAR address information through dmesg.[http://blog.frizk.net/2016/11/disable-virtualization-based-security.html] Also remove references to the kernel version to calculate the IOMMU addresses.[https://link.springer.com/content/pdf/10.1186/s13173-017-0066-7.pdf]<br />
<br />
To increase the security of the boot process if you have a TPM, you could set CONFIG_INTEL_TXT=y (which is not enabled in the hardened kernel by default) then you would need the SINIT module (provided only by Intel), a possibly compiled TrustedGrub2[https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2], trousers[https://sourceforge.net/projects/trousers/?source=navbar], tboot[https://sourceforge.net/projects/tboot/]. These packages are not in aports and it is unknown if these tools work on musl. It's not recommended for Edge. Also, there would be trigger packages to generate hashes for the kernel and the mkinitfs updates.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15199Custom Kernel2018-03-17T07:44:51Z<p>Orson Teodoro: /* But why? */ Mention Intel TxT (Intel Trusted Execution Technology)</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
You should disable modules to increase security. By default, Alpine will install modules but not disable most of them. Disabling modules will reduce an DMA attack but not eliminate it completely. If you have a newer processor with VT-d, you can mitigate as long as you:<br />
<br />
Leave CONFIG_INTEL_IOMMU_DEFAULT_ON=y or pass intel_iommu=on as a kernel parameter and disable kernel logging so the attacker doesn't gain DMAR address information through dmesg.[http://blog.frizk.net/2016/11/disable-virtualization-based-security.html] Also remove references to the kernel version to calculate the IOMMU addresses.[https://link.springer.com/content/pdf/10.1186/s13173-017-0066-7.pdf]<br />
<br />
To increase the security of the boot process if you have a TPM, you could set CONFIG_INTEL_TXT=y (which is not enabled in the hardened kernel by default) then you would need the SINIT module (provided only by Intel), a possibly compiled TrustedGrub2[https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2], trousers[https://sourceforge.net/projects/trousers/?source=navbar], tboot[https://sourceforge.net/projects/tboot/]. These packages are not in aports and it is unknown if these tools work on musl. It's not recommended for Edge. Also, there would be trigger packages to generate hashes for the kernel and the mkinitfs.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15198Custom Kernel2018-03-16T21:17:31Z<p>Orson Teodoro: /* But why? */ mention that they shouldn't disable IOMMU and put references</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
You should disable modules to increase security. By default, Alpine will install modules but not disable most of them. Disabling modules will reduce an DMA attack but not eliminate it completely. If you have a newer processor with VT-d, you can mitigate as long as you:<br />
<br />
Leave CONFIG_INTEL_IOMMU_DEFAULT_ON=y or pass intel_iommu=on as a kernel parameter and disable kernel logging so the attacker doesn't gain DMAR address information through dmesg.[http://blog.frizk.net/2016/11/disable-virtualization-based-security.html] Also remove references to the kernel version to calculate the IOMMU addresses.[https://link.springer.com/content/pdf/10.1186/s13173-017-0066-7.pdf]<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15197Custom Kernel2018-03-16T19:57:57Z<p>Orson Teodoro: /* But why? */ recommendation to increase security.</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
You should disable modules to increase security. By default, Alpine will install modules but not disable most of them. Disabling modules will reduce an DMA attack but not eliminate it completely.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15196Custom Kernel2018-03-16T18:17:33Z<p>Orson Teodoro: /* Working with aports */ put in separate paragraph</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15195Custom Kernel2018-03-16T18:16:45Z<p>Orson Teodoro: /* Working with aports */ put reason</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. You can use linux-hardened but it is being deprecated or phased out. grsecurity is the biggest patch added but its support released to the open-source community as in new updates ended.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15194Custom Kernel2018-03-16T18:14:11Z<p>Orson Teodoro: /* Working with aports */ mention you can also use deprecated hardened</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. You can use linux-hardened but it is being deprecated or phased out.<br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15193Custom Kernel2018-03-16T18:12:52Z<p>Orson Teodoro: /* Working with aports */ remove alternative since they don't want to support new kernel packages</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
We will try using an existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15192Custom Kernel2018-03-16T07:38:14Z<p>Orson Teodoro: /* Testing */ should update the bootloader also</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel. Don't forget to update your bootloader configuration.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15191Custom Kernel2018-03-16T07:37:10Z<p>Orson Teodoro: /* Testing */ fix grammar</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel, so if you use vanilla, then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15190Custom Kernel2018-03-16T07:36:39Z<p>Orson Teodoro: /* Testing */ put requirement that they should install the other kernel as a failsafe</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
Before you test, you should install the other kernel so if you use vanilla then you should <code>sudo apk add linux-hardened</code> and vice versa. You may be missing a module and can't boot, so you use the other kernel as the fallback boot kernel.<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15189Custom Kernel2018-03-16T07:31:38Z<p>Orson Teodoro: /* Testing */ fix grammar</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15188Custom Kernel2018-03-16T07:31:21Z<p>Orson Teodoro: /* Testing */ put a note for maintainers</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
If you are curious about correctness testing, the some kernel modules or components do preform self tests at the beginning of the boot process. The tools may have test suites that you run with the make command.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15187Custom Kernel2018-03-16T07:14:17Z<p>Orson Teodoro: /* Building */ put reason</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles especially if you are searching for the minimal set of options or modules to use or include.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15186Custom Kernel2018-03-16T07:11:39Z<p>Orson Teodoro: /* Building */ Add suggestion since it takes too long to compile</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
Before building, you may want to remove much modules as possible. This will reduce the time to compile greatly. Also, you may want to use ccache for faster recompiles.<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15185Custom Kernel2018-03-16T06:57:31Z<p>Orson Teodoro: /* Creating your config */ remove custom kernel and fix spelling</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copying the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your customization the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15184Custom Kernel2018-03-16T06:56:02Z<p>Orson Teodoro: /* Installing */ change custom to only vanilla or hardened</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copyting the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your custom _flavor and the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is vanilla or hardened.<br />
<br />
== Testing ==<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15183Custom Kernel2018-03-16T06:55:05Z<p>Orson Teodoro: /* Bootloader */ Delete section since there is only two flavors vanilla and hardened and they are already covered in other wiki pages</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copyting the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your custom _flavor and the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is your custom kernel release name or vanilla if you used option B.<br />
<br />
== Testing ==<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15182Custom Kernel2018-03-16T06:50:04Z<p>Orson Teodoro: /* Option B: Vanilla with native settings and minimal edits */ rename section</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Creating your config ===<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copyting the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your custom _flavor and the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is your custom kernel release name or vanilla if you used option B.<br />
<br />
== Bootloader ==<br />
<br />
You need to configure your bootloader to use the kernel. Add a new entry but do not replace the old kernel. The old kernel is your way back if the kernel config was a bad one. The naming scheme should be similar but with the tag. You should make sure that the _flavor name is attached for new kernel packages and do not override the existing vanilla kernel and the existing vanilla initramfs.<br />
<br />
For Grub, in your /boot/grub/grub.cfg if mounted should contain the new entry something like<br />
<br />
menuentry 'Alpine Linux (ck1)' {<br />
set root=(hd0,7)<br />
linux /vmlinuz-ck1 root=/dev/sda17 rw modules=sd-mod,usb-storage,ext4<br />
initrd /initramfs-ck1<br />
}<br />
<br />
In the above entry hd0,7 (in one based indexing) is associated with the boot partition /dev/sda7. /dev/sda17 should point to your userland partition containing your Alpine system files (/usr/bin, /bin, ...).<br />
<br />
If you haven't yet installed Grub, to install the bootloader with grub, you do something like <code>grub-install --force /dev/sda</code> to install it at your MBR or <code>grub-install --force /dev/sda7</code> where /dev/sda7 is your bootable drive found with <code>fdisk -l</code> depending on how you set up grub.<br />
<br />
== Testing ==<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15181Custom Kernel2018-03-16T06:49:03Z<p>Orson Teodoro: /* Option A: Creating a new kernel package */ Delete section since they are not looking for new kernel flavors</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Option B: Vanilla with native settings and minimal edits ===<br />
<br />
Most users will want to use this option.<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copyting the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your custom _flavor and the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is your custom kernel release name or vanilla if you used option B.<br />
<br />
== Bootloader ==<br />
<br />
You need to configure your bootloader to use the kernel. Add a new entry but do not replace the old kernel. The old kernel is your way back if the kernel config was a bad one. The naming scheme should be similar but with the tag. You should make sure that the _flavor name is attached for new kernel packages and do not override the existing vanilla kernel and the existing vanilla initramfs.<br />
<br />
For Grub, in your /boot/grub/grub.cfg if mounted should contain the new entry something like<br />
<br />
menuentry 'Alpine Linux (ck1)' {<br />
set root=(hd0,7)<br />
linux /vmlinuz-ck1 root=/dev/sda17 rw modules=sd-mod,usb-storage,ext4<br />
initrd /initramfs-ck1<br />
}<br />
<br />
In the above entry hd0,7 (in one based indexing) is associated with the boot partition /dev/sda7. /dev/sda17 should point to your userland partition containing your Alpine system files (/usr/bin, /bin, ...).<br />
<br />
If you haven't yet installed Grub, to install the bootloader with grub, you do something like <code>grub-install --force /dev/sda</code> to install it at your MBR or <code>grub-install --force /dev/sda7</code> where /dev/sda7 is your bootable drive found with <code>fdisk -l</code> depending on how you set up grub.<br />
<br />
== Testing ==<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Custom_Kernel&diff=15180Custom Kernel2018-03-16T06:47:51Z<p>Orson Teodoro: /* For the kernel package maintainer */ Delete section since they are not interested in adding more kernel flavors</p>
<hr />
<div>{{Draft}}<br />
<br />
This process of building a '''custom configured kernel''' assumes you are running on Alpine Linux utilizing abuild & aports.<br />
<br />
== But why? ==<br />
<br />
You want to build a custom kernel to enable experimental hardware or features or outdated hardware, to reduce bloat further, to tune the kernel to the hardware.<br />
<br />
The vanilla kernel for most Alpine ARCHs uses defaults to balance throughput at the expense of some responsiveness, and support for many devices. You can tweak the kernel for desktop use and low latency and responsiveness.<br />
<br />
== Setting up the Alpine Build System ==<br />
<br />
First, you need to follow the steps in [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]. You also need to configure your /etc/apk/repositories so that they search locally for your apks. See [[Creating_an_Alpine_package#Testing_the_package_locally|Testing the package locally]] for details.<br />
<br />
== Working with aports ==<br />
<br />
There are several ways to maintain a kernel. The first option is to create a new kernel package. The other option is to just use the existing vanilla kernel just tweaking the configure-vanilla.ARCH file. <br />
<br />
=== Switching to the proper release version ===<br />
<br />
You need to switch to the proper branch that matches the release so that the kernel compiles against the dependencies properly.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Alpine version<br />
! Remote branch<br />
|-<br />
| Edge<br />
| master<br />
|-<br />
| 3.7.0<br />
| 3.7-stable<br />
|- <br />
|}<br />
<br />
The following is required to get access to the APKBUILD released for that version of Alpine and which you will create a commit for.<br />
<br />
If you are on 3.7 do:<br />
<br />
git checkout -b 3.7-stable origin/3.7-stable<br />
<br />
If you are on Edge do:<br />
<br />
git checkout master<br />
<br />
=== Option A: Creating a new kernel package ===<br />
<br />
Use this option only if you want to want to be a kernel package maintainer or have custom patches.<br />
<br />
What you need to do is copy ''main/linux-vanilla'' folder to ''testing/linux-NAME'', where NAME could be anything but usually initials or a project name to a special kernel patch or patchset. Just use your last name if you don't know what to put. Rename all files from vanilla to NAME. Rename everything in APKBUILD from vanilla to NAME.<br />
<br />
=== Option B: Vanilla with native settings and minimal edits ===<br />
<br />
Most users will want to use this option.<br />
<br />
You can use linux-vanilla but what you should do is create a local branch by doing:<br />
<br />
For Alpine Edge:<br />
<br />
git checkout -b my-custom-kernel<br />
<br />
For Alpine 3.7:<br />
<br />
git checkout -b my-custom-kernel origin/3.7-stable<br />
<br />
Doing it this way, you do less work in maintaining. All you need to do is keep ''master'' or ''3.7-stable'' in sync[https://help.github.com/articles/syncing-a-fork/][https://help.github.com/articles/configuring-a-remote-for-a-fork/] and merge any conflicts. <br />
<br />
First switch to the branch by doing <code>git checkout my-custom-kernel</code>. Then, you need to navigate to the ''main/linux-vanilla'' folder where you should see a APKBUILD and some config- files. When you are done with your edits either by editing directly the APKBUILD and copyting the config-vanilla.ARCH as .config in the linux-4.15 folder. You will then move the .config back overriding the config-vanilla.ARCH generated by <code>make menuconfig</code> (discussed below in the ''Configuring kernel'' section). After generating your config, you need to <code>abuild checksum</code>. Then, do <code>git add APKBUILD config-vanilla.ARCH</code> where ARCH is whatever architecture (x86, x86_64, ...) you use. Then, you need to do <code>git commit APKBUILD config-NAME.ARCH -m "Enabled these options ...."</code> for your custom _flavor and the ARCHitecture of your system. You do this so that git can keep your code separate from Alpine's and so your changes float forward between kernel updates.<br />
<br />
== Adding custom patches ==<br />
<br />
Custom patches should be added to ''sources=''.<br />
<br />
After you added the URL, you need to produce a checksum by doing <code>abuild checksum</code>.<br />
<br />
The custom patches may not be autopatched, due to being distributed as an archive or different patch level, so you need to define what to do with it in the prepare().<br />
<br />
== Configuring kernel ==<br />
<br />
Attempt to build the kernel first. To do that, you do abuild -rK to install most of the dependencies. If it complains about a dependency like elfutils-dev use -rKd. Then, when it prompts for values for new found config options just hold enter till it starts compiling the kernel. There should be two sets one for -vanilla and the other for the -virt. Just Ctrl+C out of the compilation process after the second set so you can further customize the config. Then you go into the src/linux-VER and edit the config file. Copy the .config file overriding the config-NAME.ARCH in the srcdir.<br />
<br />
The alternative is to use the kernel configuration menu in the build-NAME folder, but before yo do that you need to <code>sudo apk add ncurses-dev</code><br />
<br />
After you are done using the menu in the build-NAME folder by doing <code>make menuconfig</code>, you want to remove <code>ncurses-dev</code>. When you are done, it will be stored in ''.config'' which you need to again override the config-NAME.ARCH file. When you are done updating the config-NAME.ARCH, you need to do <code>abuild checksum</code>.<br />
<br />
The options in the kernel config are typically defaults. If your device is old, it may be set to n by default.<br />
<br />
=== Vanilla targets and tuning ===<br />
<br />
{|cellpadding="5" border="1" class="wikitable"<br />
!ARCH<br />
!Processor Type / CPU Selection / System Type<br />
!Code Generation / Instruction Extensions<br />
!Timer Frequency<br />
!Preemption Model<br />
!Bitness<br />
|-<br />
|s390x<br />
|IBM zEnterprise 114 and 196<br />
|IBM zBC12 and zEC12 (<code>-march=zEC12 -mtune=zEC12</code>)<br />
|100 Hz<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc64le<br />
|Server processors<br />
|POWER8 (<code>-mcpu=power8</code>), AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>), VSX<br />
|100 HZ<br />
|No Forced Preemption (Server)<br />
|64<br />
|-<br />
|ppc<br />
|<br />
512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx<br />
* Apple PowerMac based machines<br />
|AltiVec (<code>-Wa,-maltivec</code> to assembler or <code>-maltivec -mabi=altivec</code>) on >=74xx<br />
|250 HZ<br />
|No Forced Preemption (Server)<br />
|32<br />
|-<br />
|x86_64<br />
|Generic-x86-64<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|x86<br />
|586/K5/5x86/6x86/6x86MX<br />
|(-mtune=generic ; SIMD assembly modules enabled based on simple compile test and/or presence of CPU flag)<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|armhf<br />
|<br />
* ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)<br />
* Freescale i.MX family -- Cortex A (i.MX51, i.MX53, i.MX6 Quad/DualLite, i.MX6 SoloLite, i.MX6 SoloX, i.MX6 UltraLite, i.MX7 Dual)<br />
* Qualcomm -- (MSM8X60, MSM8960, MSM8974)<br />
* Allwinner SoCs -- (A10 (sun4i), A10s / A13 (sun5i), A31 (sun6i), A20 (sun7i), sun8i Family, (sun9i))<br />
* ARM Ldt Versatile Express family -- <br />
|Either <code>-march=armv7-a</code> or <code>-march=armv5t -Wa,-march=armv7-a</code> based on a compile test. <code>-mfpu=vfp</code><br />
|100 Hz<br />
|Voluntary Kernel Preemption (Desktop)<br />
|32<br />
|-<br />
|aarch64<br />
|<br />
* Allwinner sunxi 64-bit SoC Family<br />
* Broadcom BCM2835 family<br />
* Marvell Berlin SoC Family<br />
* ARMv8 based Samsung Exynos SoC family<br />
* ARMv8 based Freescale Layerscape SoC family<br />
* Hisilicon SoC Family<br />
* Mediatek MT65xx & MT81xx ARMv8 SoC<br />
* Marvell EBU SoC Family<br />
* Qualcomm Platforms<br />
* Rockchip Platforms<br />
* AMD Seattle SoC Family<br />
* Altera's Stratix 10 SoCFPGA Family<br />
* NVIDIA Tegra SoC Family<br />
* Spreadtrum SoC platform<br />
* Cavium Inc. Thunder SoC Family<br />
* ARMv8 software model (Versatile Express)<br />
* AppliedMicro X-Gene SOC Family<br />
* Xilinx ZynqMP Family<br />
|<br />
|300 HZ<br />
|Voluntary Kernel Preemption (Desktop)<br />
|64<br />
|-<br />
|}<br />
If you do desktop multitasking, you may want to switch to Voluntary Kernel Preemption (Desktop) or Preemptible Kernel (Low-Latency Desktop) and up the Timer Frequency. If you run a dedicated render farm node or a dedicated bitcoin miner use No Forced Preemption (Server) and decrease the Timer Frequency.<br />
<br />
Optimized modules (most are already compiled as modules):<br />
* raid6 -- altivec, avx512, ssse3, avx2, mmx, sse, sse2, neon<br />
* some operations of raid5 -- mmx (32 bit), sse (64 bit), avx<br />
For Kernel API:<br />
* 32-bit memcpy -- 3dnow<br />
* 32-bit memory page clearing and copying -- sse (Athlon/K7 only), mmx<br />
From x86/crypto, arm/crypto, powerpc/crypto:<br />
* CAMELLIA -- avx2, avx, aes-ni<br />
* CHACHA20 -- avx2, neon<br />
* CAST5 -- avx<br />
* CAST6 -- avx<br />
* TWOFISH -- avx<br />
* SERPENT -- avx2, avx, sse2<br />
* SHA1 -- avx2, ssse3, neon, spe<br />
* SHA2 -- avx2<br />
* SHA256 -- ssse3, neon, spe<br />
* SHA512 -- avx2, ssse3, neon<br />
* POLY1305 -- avx2<br />
* GHASH -- pclmulqdq (part of aes-ni), vmx (power8)<br />
* AES -- aes-ni, neon, vmx (power8), spe<br />
* CRC32 -- pclmulqdq, sse, neon, vmx (power8)<br />
* CRCT10DIF -- pclmulqdq, sse, neon, vmx (power8)<br />
<br />
=== Fast reboots with kexec ===<br />
<br />
If you want to reboot the kernel fast avoiding the POST test, you need <code>sudo apk add kexec-tools</code> and enable kexec in the kernel:<br />
<br />
Processor type and features<br />
[*] kexec system call<br />
<br />
=== Hibernation to prevent data loss ===<br />
<br />
Power management and ACPI options<br />
[*] Hibernation (aka 'suspend to disk')<br />
<br />
Hibernation should be used if you have a laptop. You don't want the laptop to suddenly shut off resulting in data loss, you want it to save your work based on a percentage of battery life (this requires special script). When you do hibernation and when it restores back, it should lock down the computer and ask for prompt. Depending on your needs, the hibernated image can be encrypted/decrypted which again requires additional customization to scripts.<br />
<br />
Hibernation with an unsanitized swap file is generally insecure because data and unlocked memory pages is swapped out in plaintext. To increase the security either disable swap (Alpine default) or use an encrypted swap. The swap file/partition is typically used as a dump of the hibernated image.<br />
<br />
== Building ==<br />
<br />
You should then do an <code>abuild -r</code> to attempt to build it.<br />
<br />
== Installing ==<br />
<br />
To install it you do a <code>sudo apk add linux-NAME</code> where NAME is your custom kernel release name or vanilla if you used option B.<br />
<br />
== Bootloader ==<br />
<br />
You need to configure your bootloader to use the kernel. Add a new entry but do not replace the old kernel. The old kernel is your way back if the kernel config was a bad one. The naming scheme should be similar but with the tag. You should make sure that the _flavor name is attached for new kernel packages and do not override the existing vanilla kernel and the existing vanilla initramfs.<br />
<br />
For Grub, in your /boot/grub/grub.cfg if mounted should contain the new entry something like<br />
<br />
menuentry 'Alpine Linux (ck1)' {<br />
set root=(hd0,7)<br />
linux /vmlinuz-ck1 root=/dev/sda17 rw modules=sd-mod,usb-storage,ext4<br />
initrd /initramfs-ck1<br />
}<br />
<br />
In the above entry hd0,7 (in one based indexing) is associated with the boot partition /dev/sda7. /dev/sda17 should point to your userland partition containing your Alpine system files (/usr/bin, /bin, ...).<br />
<br />
If you haven't yet installed Grub, to install the bootloader with grub, you do something like <code>grub-install --force /dev/sda</code> to install it at your MBR or <code>grub-install --force /dev/sda7</code> where /dev/sda7 is your bootable drive found with <code>fdisk -l</code> depending on how you set up grub.<br />
<br />
== Testing ==<br />
<br />
To test, first you should make a bootable Alpine USB image. Then, when you have your rescue USB done, you <code>sudo reboot</code> the computer.<br />
<br />
To test it, you basically do trial and error. Sometimes your config is missing something if you want to have a bare minimum setting.<br />
<br />
[[Category:Kernel]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15179Setting up a laptop2018-03-15T03:58:56Z<p>Orson Teodoro: /* Important notes */ fix grammar and generalize</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition an USB thumb drive containing an encryption key retriever bypassing the operating system.[https://youtu.be/XfUlRsE3ymQ]<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15178Setting up a laptop2018-03-15T02:37:31Z<p>Orson Teodoro: /* Important notes */ put link to video so people understand</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS with Pre Boot Authentication (PBA) which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition a USB thumb drive containing an encryption key retriever bypassing the operating system.[https://youtu.be/XfUlRsE3ymQ]<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15177Setting up a laptop2018-03-15T02:36:14Z<p>Orson Teodoro: /* Important notes */ clarify</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS with Pre Boot Authentication (PBA) which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition a USB thumb drive containing an encryption key retriever bypassing the operating system.<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15176Setting up a laptop2018-03-15T02:35:16Z<p>Orson Teodoro: /* Important notes */ fix grammar</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS with Pre Boot Authentication (PBA) which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition a USB key retriever bypassing the operating system.<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15175Setting up a laptop2018-03-15T02:34:39Z<p>Orson Teodoro: /* Important notes */ fix grammar check</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS with Pre Boot Authentication (PBA) which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air with USB key retriever bypassing the operating system.<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15174Setting up a laptop2018-03-15T02:30:43Z<p>Orson Teodoro: /* Important notes */ put additional recommendation</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
You may need a custom (or customize a) BIOS with Pre Boot Authentication (PBA) which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to insert a USB and to slow down the rate of decay of the RAM module a liquid air with key retriever bypassing the operating system.<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15173Setting up a laptop2018-03-14T23:38:46Z<p>Orson Teodoro: /* Important notes */ put copy of DMA attack mitigation recommendations</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:<br />
<br />
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=LVM_on_LUKS&diff=15172LVM on LUKS2018-03-14T23:34:56Z<p>Orson Teodoro: /* Hardening */ proper addressing and expand a bit</p>
<hr />
<div>= Introduction =<br />
<br />
This documentation describes how to set up Alpine Linux using a logical volume (LV), that is installed in an encrypted partition. To encrypt the partition the logical volume manager (LVM) the volume group (VG) is installed in, the Device Mapper crypt (dm-crypt) module and Linux Unified Key Setup (LUKS) is used.<br />
<br />
Note that you must install the <code>/boot/</code> directory on an unecrypted partition to boot correctly.<br />
<br />
<br />
== Hard Disk Device Name ==<br />
<br />
The following documentation uses the <code>vda</code> device as installation destination. If your environment uses a different device name for your hard disk, use the corresponding device names in the examples.<br />
<br />
<br />
<br />
<br />
<br />
= Setting up Alpine Linux Using LVM on Top of a LUKS Partition =<br />
<br />
To install Alpine Linux in logical volumes running on top of a LUKS encrypted partition, you cannot use the [[Installation|official installation]] procedure. The installation requires several manual steps you must run in the Alpine Linux Live CD environment.<br />
<br />
<br />
<br />
== Preparing the Temporary Installation Environment ==<br />
<br />
Before you begin to install Alpine Linux, prepare the temporary environment:<br />
<br />
{{Note|All settings in this section apply only to the temporary environment and not to the later installed Alpine Linux on your hard disk.}}<br />
<br />
* Boot the latest Alpine Linux Installation CD.<br />
<br />
* At the login prompt, use the <code>root</code> user without password to log in.<br />
<br />
* Optionally, set the keyboard language:<br />
<br />
# setup-keymap<br />
<br />
: The default keyboard mapping is <code>us-us</code><br />
<br />
* Configure the network interface:<br />
<br />
# setup-interfaces<br />
<br />
: If you set a static IP address, additionally configure DNS be able to resolve host names:<br />
<br />
# setup-dns<br />
<br />
* Enable the network interface. For example:<br />
<br />
# ifup eth0<br />
<br />
* Set an apk repository and update the cache:<br />
<br />
# setup-apkrepos<br />
# apk update<br />
<br />
* Install the following packages required to set up LVM and LUKS:<br />
<br />
# apk add haveged lvm2 cryptsetup e2fsprogs syslinux<br />
<br />
: Optionally, you can install a different editor, such as <code>nano</code>, to edit files in later steps if you do not want to use VI.<br />
<br />
* Optionally, start the <code>haveged</code> service for unpredictable random numbers used for encryption:<br />
<br />
# rc-service haveged start<br />
<br />
<br />
<br />
== Creating the Partition Layout ==<br />
<br />
Linux requires an unencrypted <code>/boot/</code> partition to boot. You can assign the remaining space for the encrypted LVM physical volume (PV).<br />
<br />
* Start the <code>fdisk</code> utility to set up partitions:<br />
<br />
# fdisk /dev/vda<br />
<br />
:* Create the <code>/boot/</code> partition:<br />
::* Enter <code>n</code> &rarr; <code>p</code> &rarr; <code>1</code> &rarr; <code>1</code> &rarr; <code>100m</code> to create a new 100 MB primary partition.<br />
<br />
:* Set the <code>/boot/</code> partition active:<br />
::* Enter <code>a</code> &rarr; <code>1</code>.<br />
<br />
:* Create the LVM PV partition:<br />
::* Enter <code>n</code> &rarr; <code>p</code> &rarr; <code>2</code> to start creating the next partition. Press <code>Enter</code> to select the default start cylinder. Enter the size of partition. For example, <code>512m</code> for 512 MB or <code>5g</code> for 5 GB. Alternatively press <code>Enter</code> to set the maximum available size.<br />
<br />
:* Set the partition type for the LVM PV:<br />
::* Enter <code>t</code> &rarr; <code>2</code> &rarr; <code>8e</code><br />
<br />
:* To verify the settings, press <code>p</code>. The output shows, for example:<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/vda1 * 1 100 50368+ 83 Linux<br />
/dev/vda2 101 10402 5192208 8e Linux LVM<br />
<br />
* Press <code>w</code> to save the changes.<br />
<br />
* Optionally, wipe the LVM PV partition with random values:<br />
<br />
# haveged -n 0 | dd of=/dev/vda2<br />
<br />
: Depending on the size of the partition, this process can take several minutes to hours.<br />
<br />
<br />
<br />
== Encrypting the LVM Physical Volume Partition == <br />
<br />
* To encrypt the partition which will later contain the LVM PV:<br />
<br />
# cryptsetup luksFormat /dev/vda2<br />
<br />
:{{Note|Alpine Linux uses the <code>en-us</code> keyboard mapping when prompting for the password to encrypt the partition at boot time. If you changed the keyboard map in the temporary environment, the password you enter during encrypting the partition in this step, may not match the password you will enter during the system boots.}}<br />
: If you prefer setting an individual hashing algorithm and hashing schema:<br />
:* To run a benchmark:<br />
<br />
# cryptsetup benchmark<br />
<br />
:* To encrypt the partition using individual settings, enter, for example:<br />
<br />
# cryptsetup -v -c serpent-xts-plain64 -s 512 --hash whirlpool --iter-time 5000 --use-random luksFormat /dev/vda2<br />
<br />
<br />
<br />
== Creating the Logical Volumes and File Systems ==<br />
<br />
* Open the LUKS partition:<br />
<br />
# cryptsetup open --type luks /dev/vda2 lvmcrypt<br />
<br />
* Create the PV on <code>/dev/vda</code>:<br />
<br />
# pvcreate /dev/mapper/lvmcrypt<br />
<br />
* Create the <code>vg0</code> LVM VG in the <code>/dev/mapper/lvmcrypt</code> PV:<br />
<br />
# vgcreate vg0 /dev/mapper/lvmcrypt<br />
<br />
* Create the LVs:<br />
<br />
: In the following you will create a LV for the root partition. However, you can use the same command with a different LV name to create further LVs for other mount points you want to create.<br />
<br />
:* To create a 2 GB LV named <code>root</code> in the <code>vg0</code> VG:<br />
<br />
# lvcreate -L 2G vg0 -n root<br />
<br />
: Create a 512 MB swap LV:<br />
<br />
# lvcreate -L 512M vg0 -n swap<br />
<br />
* The LVs created in the previous steps are automatically marked active. To verify, enter:<br />
<br />
# lvscan<br />
<br />
: Format the <code>root</code> LV using the ext4 file system:<br />
<br />
# mkfs.ext4 /dev/vg0/root<br />
<br />
: If you created further LVs in the previous step, create the file systems on them using the same command with the path to the LV.<br />
<br />
* Format the swap LV:<br />
<br />
# mkswap /dev/vg0/swap<br />
<br />
* Format the <code>/dev/vda1</code> device for the <code>/boot/</code> partition using the ext4 file system:<br />
<br />
# mkfs.ext4 /dev/vda1<br />
<br />
<br />
<br />
== Mounting the File Systems ==<br />
<br />
Before you can install Alpine Linux, you must mount the partitions and LVs:<br />
<br />
* Mount the root LV to the <code>/mnt/</code> directory:<br />
<br />
# mount -t ext4 /dev/vg0/root /mnt/<br />
<br />
* Create <code>/mnt/boot/</code> directory and mount the <code>/dev/vda1</code> partition in this directory:<br />
<br />
# mkdir /mnt/boot/<br />
# mount -t ext4 /dev/vda1 /mnt/boot/<br />
<br />
: If you created further partitions or LVs, create the mount points within the <code>/mnt/</code> directory and mount the devices.<br />
<br />
== Installing Alpine Linux ==<br />
<br />
In this step you will install Alpine Linux in the <code>/mnt/</code> directory, which contains the mounted file system structure:<br />
<br />
* Install Alpine Linux:<br />
<br />
# setup-disk -m sys /mnt/<br />
<br />
: The installer downloads the latest packages to install the base installation. Additionally, the installer automatically creates the entries for the mount points in the <code>fstab</code> file, which are currently mounted in the <code>/mnt/</code> directory.<br />
<br />
: {{Note|The automatic writing of the master boot record (MBR) fails in this step. You will write the MBR later manually to the disk.}}<br />
<br />
* To enable the operating system to decrypt the PV at boot time, create the <code>/mnt/etc/crypttab</code> file. Enter the following line into the file to decrypt the <code>/dev/vda2</code> partition using the <code>luks</code> module and map it to the <code>lvmcrypt</code> name:<br />
<br />
lvmcrypt /dev/vda2 none luks<br />
<br />
* The swap LV is not automatically added to the <code>fstab</code> file. To add it manually, add the following line to the <code>/mnt/etc/fstab</code> file:<br />
<br />
/dev/vg0/swap swap swap defaults 0 0<br />
<br />
* Edit the <code>/mnt/etc/mkinitfs/mkinitfs.conf</code> file and append the <code>cryptsetup</code> module to the <code>features</code> parameter:<br />
<br />
features="ata base ide scsi usb virtio ext4 lvm <u>cryptsetup</u>"<br />
<br />
* Rebuild the initial RAM disk:<br />
<br />
# mkinitfs -c /mnt/etc/mkinitfs/mkinitfs.conf -b /mnt/ $(ls /mnt/lib/modules/)<br />
<br />
: The command uses the settings from the <code>mkinitfs.conf</code> file set in the <code>-c</code> parameter to generate the RAM disk. The command is executed in the <code>/mnt/</code> directory and the RAM disk is generated using the modules for the installed kernel. Without setting the kernel version using the <code>$(ls /mnt/lib/modules/</code>) option, <code>mkinitfs</code> tries to generate the RAM disk using the kernel version installed in the temporary environment, which can differ from the latest one installed by the <code>setup-disk</code> utility.<br />
<br />
* Edit the <code>/mnt/etc/update-extlinux.conf</code> file and append the following kernel options to the <code>default_kernel_opts</code> parameter:<br />
<br />
default_kernel_opts="... <u>cryptroot=/dev/vda2 cryptdm=lvmcrypt</u>"<br />
<br />
: The <code>cryptroot</code> parameter sets the name of the device that contains the root file system. The <code>cryptdm</code> parameter sets the name of the mapping previously set in the <code>crypttab</code> file.<br />
<br />
* Because the <code>update-extlinux</code> utility operators only on the <code>/boot/</code> directory, temporarily change the root to the <code>/mnt/</code> directory and update the boot loader configuration:<br />
<br />
# chroot /mnt/<br />
# update-extlinux<br />
# exit<br />
<br />
: Ignore the errors the <code>update-extlinux</code> utility displays.<br />
<br />
* Write the MBR to the <code>/dev/vda</code> device:<br />
<br />
# dd bs=440 count=1 conv=notrunc if=/mnt/usr/share/syslinux/mbr.bin of=/dev/vda<br />
<br />
== Unmounting the Volumes and Partitions ==<br />
<br />
* Umount <code>/mnt/boot/</code> and <code>/mnt/</code>:<br />
<br />
# umount /mnt/boot/<br />
# umount /mnt/<br />
<br />
: {{Note|If you mounted further partitions or LVs below <code>/mnt/</code>, you must first unmount all of them before you can unmount <code>/mnt/</code>.}}<br />
<br />
* Disable the swap partition:<br />
<br />
# swapoff -a<br />
<br />
* Deactivate the VG:<br />
<br />
# vgchange -a n<br />
<br />
* Close the <code>lvmcrypt</code> device:<br />
<br />
# cryptsetup luksClose lvmcrypt<br />
<br />
* Reboot the system:<br />
<br />
# reboot<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
== General Procedure ==<br />
<br />
In case your system fails to boot, you can verify the settings and fix incorrect configurations:<br />
<br />
* [[#Preparing_the_Temporary_Installation_Environment|Prepare the temporary installation environment]]<br />
<br />
* Activate the VGs:<br />
<br />
# vgchange -a y<br />
<br />
* [[#Mounting_the_File_Systems|Mount the file systems]]<br />
<br />
* Verify that you run the steps described in the [[#Installing_Alpine_Linux|Installing Alpine Linux]] section correctly. Update the configuration if necessary.<br />
<br />
* [[#Unmounting_the_Volumes_and_Partitions|Unmount the volumes and partitions]]<br />
<br />
= Hardening =<br />
<br />
* To harden, you should disable DMA[https://old.iseclab.org/papers/acsac2012dma.pdf] and install a hardened version of AES (TRESOR[https://www1.informatik.uni-erlangen.de/tresor] or Loop-Amnesia[http://moongate.ydns.eu/amnesia.html]) since by default cryptsetup with luks uses AES by default.<br />
* Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
* Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.<br />
<br />
[[Category:Storage]]<br />
[[Category:Security]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=LVM_on_LUKS&diff=15171LVM on LUKS2018-03-14T23:26:31Z<p>Orson Teodoro: /* Hardening */ put another recommendation</p>
<hr />
<div>= Introduction =<br />
<br />
This documentation describes how to set up Alpine Linux using a logical volume (LV), that is installed in an encrypted partition. To encrypt the partition the logical volume manager (LVM) the volume group (VG) is installed in, the Device Mapper crypt (dm-crypt) module and Linux Unified Key Setup (LUKS) is used.<br />
<br />
Note that you must install the <code>/boot/</code> directory on an unecrypted partition to boot correctly.<br />
<br />
<br />
== Hard Disk Device Name ==<br />
<br />
The following documentation uses the <code>vda</code> device as installation destination. If your environment uses a different device name for your hard disk, use the corresponding device names in the examples.<br />
<br />
<br />
<br />
<br />
<br />
= Setting up Alpine Linux Using LVM on Top of a LUKS Partition =<br />
<br />
To install Alpine Linux in logical volumes running on top of a LUKS encrypted partition, you cannot use the [[Installation|official installation]] procedure. The installation requires several manual steps you must run in the Alpine Linux Live CD environment.<br />
<br />
<br />
<br />
== Preparing the Temporary Installation Environment ==<br />
<br />
Before you begin to install Alpine Linux, prepare the temporary environment:<br />
<br />
{{Note|All settings in this section apply only to the temporary environment and not to the later installed Alpine Linux on your hard disk.}}<br />
<br />
* Boot the latest Alpine Linux Installation CD.<br />
<br />
* At the login prompt, use the <code>root</code> user without password to log in.<br />
<br />
* Optionally, set the keyboard language:<br />
<br />
# setup-keymap<br />
<br />
: The default keyboard mapping is <code>us-us</code><br />
<br />
* Configure the network interface:<br />
<br />
# setup-interfaces<br />
<br />
: If you set a static IP address, additionally configure DNS be able to resolve host names:<br />
<br />
# setup-dns<br />
<br />
* Enable the network interface. For example:<br />
<br />
# ifup eth0<br />
<br />
* Set an apk repository and update the cache:<br />
<br />
# setup-apkrepos<br />
# apk update<br />
<br />
* Install the following packages required to set up LVM and LUKS:<br />
<br />
# apk add haveged lvm2 cryptsetup e2fsprogs syslinux<br />
<br />
: Optionally, you can install a different editor, such as <code>nano</code>, to edit files in later steps if you do not want to use VI.<br />
<br />
* Optionally, start the <code>haveged</code> service for unpredictable random numbers used for encryption:<br />
<br />
# rc-service haveged start<br />
<br />
<br />
<br />
== Creating the Partition Layout ==<br />
<br />
Linux requires an unencrypted <code>/boot/</code> partition to boot. You can assign the remaining space for the encrypted LVM physical volume (PV).<br />
<br />
* Start the <code>fdisk</code> utility to set up partitions:<br />
<br />
# fdisk /dev/vda<br />
<br />
:* Create the <code>/boot/</code> partition:<br />
::* Enter <code>n</code> &rarr; <code>p</code> &rarr; <code>1</code> &rarr; <code>1</code> &rarr; <code>100m</code> to create a new 100 MB primary partition.<br />
<br />
:* Set the <code>/boot/</code> partition active:<br />
::* Enter <code>a</code> &rarr; <code>1</code>.<br />
<br />
:* Create the LVM PV partition:<br />
::* Enter <code>n</code> &rarr; <code>p</code> &rarr; <code>2</code> to start creating the next partition. Press <code>Enter</code> to select the default start cylinder. Enter the size of partition. For example, <code>512m</code> for 512 MB or <code>5g</code> for 5 GB. Alternatively press <code>Enter</code> to set the maximum available size.<br />
<br />
:* Set the partition type for the LVM PV:<br />
::* Enter <code>t</code> &rarr; <code>2</code> &rarr; <code>8e</code><br />
<br />
:* To verify the settings, press <code>p</code>. The output shows, for example:<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/vda1 * 1 100 50368+ 83 Linux<br />
/dev/vda2 101 10402 5192208 8e Linux LVM<br />
<br />
* Press <code>w</code> to save the changes.<br />
<br />
* Optionally, wipe the LVM PV partition with random values:<br />
<br />
# haveged -n 0 | dd of=/dev/vda2<br />
<br />
: Depending on the size of the partition, this process can take several minutes to hours.<br />
<br />
<br />
<br />
== Encrypting the LVM Physical Volume Partition == <br />
<br />
* To encrypt the partition which will later contain the LVM PV:<br />
<br />
# cryptsetup luksFormat /dev/vda2<br />
<br />
:{{Note|Alpine Linux uses the <code>en-us</code> keyboard mapping when prompting for the password to encrypt the partition at boot time. If you changed the keyboard map in the temporary environment, the password you enter during encrypting the partition in this step, may not match the password you will enter during the system boots.}}<br />
: If you prefer setting an individual hashing algorithm and hashing schema:<br />
:* To run a benchmark:<br />
<br />
# cryptsetup benchmark<br />
<br />
:* To encrypt the partition using individual settings, enter, for example:<br />
<br />
# cryptsetup -v -c serpent-xts-plain64 -s 512 --hash whirlpool --iter-time 5000 --use-random luksFormat /dev/vda2<br />
<br />
<br />
<br />
== Creating the Logical Volumes and File Systems ==<br />
<br />
* Open the LUKS partition:<br />
<br />
# cryptsetup open --type luks /dev/vda2 lvmcrypt<br />
<br />
* Create the PV on <code>/dev/vda</code>:<br />
<br />
# pvcreate /dev/mapper/lvmcrypt<br />
<br />
* Create the <code>vg0</code> LVM VG in the <code>/dev/mapper/lvmcrypt</code> PV:<br />
<br />
# vgcreate vg0 /dev/mapper/lvmcrypt<br />
<br />
* Create the LVs:<br />
<br />
: In the following you will create a LV for the root partition. However, you can use the same command with a different LV name to create further LVs for other mount points you want to create.<br />
<br />
:* To create a 2 GB LV named <code>root</code> in the <code>vg0</code> VG:<br />
<br />
# lvcreate -L 2G vg0 -n root<br />
<br />
: Create a 512 MB swap LV:<br />
<br />
# lvcreate -L 512M vg0 -n swap<br />
<br />
* The LVs created in the previous steps are automatically marked active. To verify, enter:<br />
<br />
# lvscan<br />
<br />
: Format the <code>root</code> LV using the ext4 file system:<br />
<br />
# mkfs.ext4 /dev/vg0/root<br />
<br />
: If you created further LVs in the previous step, create the file systems on them using the same command with the path to the LV.<br />
<br />
* Format the swap LV:<br />
<br />
# mkswap /dev/vg0/swap<br />
<br />
* Format the <code>/dev/vda1</code> device for the <code>/boot/</code> partition using the ext4 file system:<br />
<br />
# mkfs.ext4 /dev/vda1<br />
<br />
<br />
<br />
== Mounting the File Systems ==<br />
<br />
Before you can install Alpine Linux, you must mount the partitions and LVs:<br />
<br />
* Mount the root LV to the <code>/mnt/</code> directory:<br />
<br />
# mount -t ext4 /dev/vg0/root /mnt/<br />
<br />
* Create <code>/mnt/boot/</code> directory and mount the <code>/dev/vda1</code> partition in this directory:<br />
<br />
# mkdir /mnt/boot/<br />
# mount -t ext4 /dev/vda1 /mnt/boot/<br />
<br />
: If you created further partitions or LVs, create the mount points within the <code>/mnt/</code> directory and mount the devices.<br />
<br />
== Installing Alpine Linux ==<br />
<br />
In this step you will install Alpine Linux in the <code>/mnt/</code> directory, which contains the mounted file system structure:<br />
<br />
* Install Alpine Linux:<br />
<br />
# setup-disk -m sys /mnt/<br />
<br />
: The installer downloads the latest packages to install the base installation. Additionally, the installer automatically creates the entries for the mount points in the <code>fstab</code> file, which are currently mounted in the <code>/mnt/</code> directory.<br />
<br />
: {{Note|The automatic writing of the master boot record (MBR) fails in this step. You will write the MBR later manually to the disk.}}<br />
<br />
* To enable the operating system to decrypt the PV at boot time, create the <code>/mnt/etc/crypttab</code> file. Enter the following line into the file to decrypt the <code>/dev/vda2</code> partition using the <code>luks</code> module and map it to the <code>lvmcrypt</code> name:<br />
<br />
lvmcrypt /dev/vda2 none luks<br />
<br />
* The swap LV is not automatically added to the <code>fstab</code> file. To add it manually, add the following line to the <code>/mnt/etc/fstab</code> file:<br />
<br />
/dev/vg0/swap swap swap defaults 0 0<br />
<br />
* Edit the <code>/mnt/etc/mkinitfs/mkinitfs.conf</code> file and append the <code>cryptsetup</code> module to the <code>features</code> parameter:<br />
<br />
features="ata base ide scsi usb virtio ext4 lvm <u>cryptsetup</u>"<br />
<br />
* Rebuild the initial RAM disk:<br />
<br />
# mkinitfs -c /mnt/etc/mkinitfs/mkinitfs.conf -b /mnt/ $(ls /mnt/lib/modules/)<br />
<br />
: The command uses the settings from the <code>mkinitfs.conf</code> file set in the <code>-c</code> parameter to generate the RAM disk. The command is executed in the <code>/mnt/</code> directory and the RAM disk is generated using the modules for the installed kernel. Without setting the kernel version using the <code>$(ls /mnt/lib/modules/</code>) option, <code>mkinitfs</code> tries to generate the RAM disk using the kernel version installed in the temporary environment, which can differ from the latest one installed by the <code>setup-disk</code> utility.<br />
<br />
* Edit the <code>/mnt/etc/update-extlinux.conf</code> file and append the following kernel options to the <code>default_kernel_opts</code> parameter:<br />
<br />
default_kernel_opts="... <u>cryptroot=/dev/vda2 cryptdm=lvmcrypt</u>"<br />
<br />
: The <code>cryptroot</code> parameter sets the name of the device that contains the root file system. The <code>cryptdm</code> parameter sets the name of the mapping previously set in the <code>crypttab</code> file.<br />
<br />
* Because the <code>update-extlinux</code> utility operators only on the <code>/boot/</code> directory, temporarily change the root to the <code>/mnt/</code> directory and update the boot loader configuration:<br />
<br />
# chroot /mnt/<br />
# update-extlinux<br />
# exit<br />
<br />
: Ignore the errors the <code>update-extlinux</code> utility displays.<br />
<br />
* Write the MBR to the <code>/dev/vda</code> device:<br />
<br />
# dd bs=440 count=1 conv=notrunc if=/mnt/usr/share/syslinux/mbr.bin of=/dev/vda<br />
<br />
== Unmounting the Volumes and Partitions ==<br />
<br />
* Umount <code>/mnt/boot/</code> and <code>/mnt/</code>:<br />
<br />
# umount /mnt/boot/<br />
# umount /mnt/<br />
<br />
: {{Note|If you mounted further partitions or LVs below <code>/mnt/</code>, you must first unmount all of them before you can unmount <code>/mnt/</code>.}}<br />
<br />
* Disable the swap partition:<br />
<br />
# swapoff -a<br />
<br />
* Deactivate the VG:<br />
<br />
# vgchange -a n<br />
<br />
* Close the <code>lvmcrypt</code> device:<br />
<br />
# cryptsetup luksClose lvmcrypt<br />
<br />
* Reboot the system:<br />
<br />
# reboot<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
== General Procedure ==<br />
<br />
In case your system fails to boot, you can verify the settings and fix incorrect configurations:<br />
<br />
* [[#Preparing_the_Temporary_Installation_Environment|Prepare the temporary installation environment]]<br />
<br />
* Activate the VGs:<br />
<br />
# vgchange -a y<br />
<br />
* [[#Mounting_the_File_Systems|Mount the file systems]]<br />
<br />
* Verify that you run the steps described in the [[#Installing_Alpine_Linux|Installing Alpine Linux]] section correctly. Update the configuration if necessary.<br />
<br />
* [[#Unmounting_the_Volumes_and_Partitions|Unmount the volumes and partitions]]<br />
<br />
= Hardening =<br />
<br />
* To harden, you should disable DMA[https://old.iseclab.org/papers/acsac2012dma.pdf] and install a hardened version of AES (TRESOR[https://www1.informatik.uni-erlangen.de/tresor] or LoopAmnesia[http://moongate.ydns.eu/amnesia.html]) since by default cryptsetup with luks uses AES by default.<br />
* Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
* Blacklist kernel modules that use DMA.<br />
<br />
[[Category:Storage]]<br />
[[Category:Security]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=LVM_on_LUKS&diff=15170LVM on LUKS2018-03-14T23:23:16Z<p>Orson Teodoro: /* Hardening */ add recommendation</p>
<hr />
<div>= Introduction =<br />
<br />
This documentation describes how to set up Alpine Linux using a logical volume (LV), that is installed in an encrypted partition. To encrypt the partition the logical volume manager (LVM) the volume group (VG) is installed in, the Device Mapper crypt (dm-crypt) module and Linux Unified Key Setup (LUKS) is used.<br />
<br />
Note that you must install the <code>/boot/</code> directory on an unecrypted partition to boot correctly.<br />
<br />
<br />
== Hard Disk Device Name ==<br />
<br />
The following documentation uses the <code>vda</code> device as installation destination. If your environment uses a different device name for your hard disk, use the corresponding device names in the examples.<br />
<br />
<br />
<br />
<br />
<br />
= Setting up Alpine Linux Using LVM on Top of a LUKS Partition =<br />
<br />
To install Alpine Linux in logical volumes running on top of a LUKS encrypted partition, you cannot use the [[Installation|official installation]] procedure. The installation requires several manual steps you must run in the Alpine Linux Live CD environment.<br />
<br />
<br />
<br />
== Preparing the Temporary Installation Environment ==<br />
<br />
Before you begin to install Alpine Linux, prepare the temporary environment:<br />
<br />
{{Note|All settings in this section apply only to the temporary environment and not to the later installed Alpine Linux on your hard disk.}}<br />
<br />
* Boot the latest Alpine Linux Installation CD.<br />
<br />
* At the login prompt, use the <code>root</code> user without password to log in.<br />
<br />
* Optionally, set the keyboard language:<br />
<br />
# setup-keymap<br />
<br />
: The default keyboard mapping is <code>us-us</code><br />
<br />
* Configure the network interface:<br />
<br />
# setup-interfaces<br />
<br />
: If you set a static IP address, additionally configure DNS be able to resolve host names:<br />
<br />
# setup-dns<br />
<br />
* Enable the network interface. For example:<br />
<br />
# ifup eth0<br />
<br />
* Set an apk repository and update the cache:<br />
<br />
# setup-apkrepos<br />
# apk update<br />
<br />
* Install the following packages required to set up LVM and LUKS:<br />
<br />
# apk add haveged lvm2 cryptsetup e2fsprogs syslinux<br />
<br />
: Optionally, you can install a different editor, such as <code>nano</code>, to edit files in later steps if you do not want to use VI.<br />
<br />
* Optionally, start the <code>haveged</code> service for unpredictable random numbers used for encryption:<br />
<br />
# rc-service haveged start<br />
<br />
<br />
<br />
== Creating the Partition Layout ==<br />
<br />
Linux requires an unencrypted <code>/boot/</code> partition to boot. You can assign the remaining space for the encrypted LVM physical volume (PV).<br />
<br />
* Start the <code>fdisk</code> utility to set up partitions:<br />
<br />
# fdisk /dev/vda<br />
<br />
:* Create the <code>/boot/</code> partition:<br />
::* Enter <code>n</code> &rarr; <code>p</code> &rarr; <code>1</code> &rarr; <code>1</code> &rarr; <code>100m</code> to create a new 100 MB primary partition.<br />
<br />
:* Set the <code>/boot/</code> partition active:<br />
::* Enter <code>a</code> &rarr; <code>1</code>.<br />
<br />
:* Create the LVM PV partition:<br />
::* Enter <code>n</code> &rarr; <code>p</code> &rarr; <code>2</code> to start creating the next partition. Press <code>Enter</code> to select the default start cylinder. Enter the size of partition. For example, <code>512m</code> for 512 MB or <code>5g</code> for 5 GB. Alternatively press <code>Enter</code> to set the maximum available size.<br />
<br />
:* Set the partition type for the LVM PV:<br />
::* Enter <code>t</code> &rarr; <code>2</code> &rarr; <code>8e</code><br />
<br />
:* To verify the settings, press <code>p</code>. The output shows, for example:<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/vda1 * 1 100 50368+ 83 Linux<br />
/dev/vda2 101 10402 5192208 8e Linux LVM<br />
<br />
* Press <code>w</code> to save the changes.<br />
<br />
* Optionally, wipe the LVM PV partition with random values:<br />
<br />
# haveged -n 0 | dd of=/dev/vda2<br />
<br />
: Depending on the size of the partition, this process can take several minutes to hours.<br />
<br />
<br />
<br />
== Encrypting the LVM Physical Volume Partition == <br />
<br />
* To encrypt the partition which will later contain the LVM PV:<br />
<br />
# cryptsetup luksFormat /dev/vda2<br />
<br />
:{{Note|Alpine Linux uses the <code>en-us</code> keyboard mapping when prompting for the password to encrypt the partition at boot time. If you changed the keyboard map in the temporary environment, the password you enter during encrypting the partition in this step, may not match the password you will enter during the system boots.}}<br />
: If you prefer setting an individual hashing algorithm and hashing schema:<br />
:* To run a benchmark:<br />
<br />
# cryptsetup benchmark<br />
<br />
:* To encrypt the partition using individual settings, enter, for example:<br />
<br />
# cryptsetup -v -c serpent-xts-plain64 -s 512 --hash whirlpool --iter-time 5000 --use-random luksFormat /dev/vda2<br />
<br />
<br />
<br />
== Creating the Logical Volumes and File Systems ==<br />
<br />
* Open the LUKS partition:<br />
<br />
# cryptsetup open --type luks /dev/vda2 lvmcrypt<br />
<br />
* Create the PV on <code>/dev/vda</code>:<br />
<br />
# pvcreate /dev/mapper/lvmcrypt<br />
<br />
* Create the <code>vg0</code> LVM VG in the <code>/dev/mapper/lvmcrypt</code> PV:<br />
<br />
# vgcreate vg0 /dev/mapper/lvmcrypt<br />
<br />
* Create the LVs:<br />
<br />
: In the following you will create a LV for the root partition. However, you can use the same command with a different LV name to create further LVs for other mount points you want to create.<br />
<br />
:* To create a 2 GB LV named <code>root</code> in the <code>vg0</code> VG:<br />
<br />
# lvcreate -L 2G vg0 -n root<br />
<br />
: Create a 512 MB swap LV:<br />
<br />
# lvcreate -L 512M vg0 -n swap<br />
<br />
* The LVs created in the previous steps are automatically marked active. To verify, enter:<br />
<br />
# lvscan<br />
<br />
: Format the <code>root</code> LV using the ext4 file system:<br />
<br />
# mkfs.ext4 /dev/vg0/root<br />
<br />
: If you created further LVs in the previous step, create the file systems on them using the same command with the path to the LV.<br />
<br />
* Format the swap LV:<br />
<br />
# mkswap /dev/vg0/swap<br />
<br />
* Format the <code>/dev/vda1</code> device for the <code>/boot/</code> partition using the ext4 file system:<br />
<br />
# mkfs.ext4 /dev/vda1<br />
<br />
<br />
<br />
== Mounting the File Systems ==<br />
<br />
Before you can install Alpine Linux, you must mount the partitions and LVs:<br />
<br />
* Mount the root LV to the <code>/mnt/</code> directory:<br />
<br />
# mount -t ext4 /dev/vg0/root /mnt/<br />
<br />
* Create <code>/mnt/boot/</code> directory and mount the <code>/dev/vda1</code> partition in this directory:<br />
<br />
# mkdir /mnt/boot/<br />
# mount -t ext4 /dev/vda1 /mnt/boot/<br />
<br />
: If you created further partitions or LVs, create the mount points within the <code>/mnt/</code> directory and mount the devices.<br />
<br />
== Installing Alpine Linux ==<br />
<br />
In this step you will install Alpine Linux in the <code>/mnt/</code> directory, which contains the mounted file system structure:<br />
<br />
* Install Alpine Linux:<br />
<br />
# setup-disk -m sys /mnt/<br />
<br />
: The installer downloads the latest packages to install the base installation. Additionally, the installer automatically creates the entries for the mount points in the <code>fstab</code> file, which are currently mounted in the <code>/mnt/</code> directory.<br />
<br />
: {{Note|The automatic writing of the master boot record (MBR) fails in this step. You will write the MBR later manually to the disk.}}<br />
<br />
* To enable the operating system to decrypt the PV at boot time, create the <code>/mnt/etc/crypttab</code> file. Enter the following line into the file to decrypt the <code>/dev/vda2</code> partition using the <code>luks</code> module and map it to the <code>lvmcrypt</code> name:<br />
<br />
lvmcrypt /dev/vda2 none luks<br />
<br />
* The swap LV is not automatically added to the <code>fstab</code> file. To add it manually, add the following line to the <code>/mnt/etc/fstab</code> file:<br />
<br />
/dev/vg0/swap swap swap defaults 0 0<br />
<br />
* Edit the <code>/mnt/etc/mkinitfs/mkinitfs.conf</code> file and append the <code>cryptsetup</code> module to the <code>features</code> parameter:<br />
<br />
features="ata base ide scsi usb virtio ext4 lvm <u>cryptsetup</u>"<br />
<br />
* Rebuild the initial RAM disk:<br />
<br />
# mkinitfs -c /mnt/etc/mkinitfs/mkinitfs.conf -b /mnt/ $(ls /mnt/lib/modules/)<br />
<br />
: The command uses the settings from the <code>mkinitfs.conf</code> file set in the <code>-c</code> parameter to generate the RAM disk. The command is executed in the <code>/mnt/</code> directory and the RAM disk is generated using the modules for the installed kernel. Without setting the kernel version using the <code>$(ls /mnt/lib/modules/</code>) option, <code>mkinitfs</code> tries to generate the RAM disk using the kernel version installed in the temporary environment, which can differ from the latest one installed by the <code>setup-disk</code> utility.<br />
<br />
* Edit the <code>/mnt/etc/update-extlinux.conf</code> file and append the following kernel options to the <code>default_kernel_opts</code> parameter:<br />
<br />
default_kernel_opts="... <u>cryptroot=/dev/vda2 cryptdm=lvmcrypt</u>"<br />
<br />
: The <code>cryptroot</code> parameter sets the name of the device that contains the root file system. The <code>cryptdm</code> parameter sets the name of the mapping previously set in the <code>crypttab</code> file.<br />
<br />
* Because the <code>update-extlinux</code> utility operators only on the <code>/boot/</code> directory, temporarily change the root to the <code>/mnt/</code> directory and update the boot loader configuration:<br />
<br />
# chroot /mnt/<br />
# update-extlinux<br />
# exit<br />
<br />
: Ignore the errors the <code>update-extlinux</code> utility displays.<br />
<br />
* Write the MBR to the <code>/dev/vda</code> device:<br />
<br />
# dd bs=440 count=1 conv=notrunc if=/mnt/usr/share/syslinux/mbr.bin of=/dev/vda<br />
<br />
== Unmounting the Volumes and Partitions ==<br />
<br />
* Umount <code>/mnt/boot/</code> and <code>/mnt/</code>:<br />
<br />
# umount /mnt/boot/<br />
# umount /mnt/<br />
<br />
: {{Note|If you mounted further partitions or LVs below <code>/mnt/</code>, you must first unmount all of them before you can unmount <code>/mnt/</code>.}}<br />
<br />
* Disable the swap partition:<br />
<br />
# swapoff -a<br />
<br />
* Deactivate the VG:<br />
<br />
# vgchange -a n<br />
<br />
* Close the <code>lvmcrypt</code> device:<br />
<br />
# cryptsetup luksClose lvmcrypt<br />
<br />
* Reboot the system:<br />
<br />
# reboot<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
== General Procedure ==<br />
<br />
In case your system fails to boot, you can verify the settings and fix incorrect configurations:<br />
<br />
* [[#Preparing_the_Temporary_Installation_Environment|Prepare the temporary installation environment]]<br />
<br />
* Activate the VGs:<br />
<br />
# vgchange -a y<br />
<br />
* [[#Mounting_the_File_Systems|Mount the file systems]]<br />
<br />
* Verify that you run the steps described in the [[#Installing_Alpine_Linux|Installing Alpine Linux]] section correctly. Update the configuration if necessary.<br />
<br />
* [[#Unmounting_the_Volumes_and_Partitions|Unmount the volumes and partitions]]<br />
<br />
= Hardening =<br />
<br />
* To harden, you should disable DMA[https://old.iseclab.org/papers/acsac2012dma.pdf] and install a hardened version of AES (TRESOR[https://www1.informatik.uni-erlangen.de/tresor] or LoopAmnesia[http://moongate.ydns.eu/amnesia.html]) since by default cryptsetup with luks uses AES by default.<br />
* Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]<br />
<br />
[[Category:Storage]]<br />
[[Category:Security]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=LVM_on_LUKS&diff=15169LVM on LUKS2018-03-14T21:22:17Z<p>Orson Teodoro: /* Hardening */ more precise language</p>
<hr />
<div>= Introduction =<br />
<br />
This documentation describes how to set up Alpine Linux using a logical volume (LV), that is installed in an encrypted partition. To encrypt the partition the logical volume manager (LVM) the volume group (VG) is installed in, the Device Mapper crypt (dm-crypt) module and Linux Unified Key Setup (LUKS) is used.<br />
<br />
Note that you must install the <code>/boot/</code> directory on an unecrypted partition to boot correctly.<br />
<br />
<br />
== Hard Disk Device Name ==<br />
<br />
The following documentation uses the <code>vda</code> device as installation destination. If your environment uses a different device name for your hard disk, use the corresponding device names in the examples.<br />
<br />
<br />
<br />
<br />
<br />
= Setting up Alpine Linux Using LVM on Top of a LUKS Partition =<br />
<br />
To install Alpine Linux in logical volumes running on top of a LUKS encrypted partition, you cannot use the [[Installation|official installation]] procedure. The installation requires several manual steps you must run in the Alpine Linux Live CD environment.<br />
<br />
<br />
<br />
== Preparing the Temporary Installation Environment ==<br />
<br />
Before you begin to install Alpine Linux, prepare the temporary environment:<br />
<br />
{{Note|All settings in this section apply only to the temporary environment and not to the later installed Alpine Linux on your hard disk.}}<br />
<br />
* Boot the latest Alpine Linux Installation CD.<br />
<br />
* At the login prompt, use the <code>root</code> user without password to log in.<br />
<br />
* Optionally, set the keyboard language:<br />
<br />
# setup-keymap<br />
<br />
: The default keyboard mapping is <code>us-us</code><br />
<br />
* Configure the network interface:<br />
<br />
# setup-interfaces<br />
<br />
: If you set a static IP address, additionally configure DNS be able to resolve host names:<br />
<br />
# setup-dns<br />
<br />
* Enable the network interface. For example:<br />
<br />
# ifup eth0<br />
<br />
* Set an apk repository and update the cache:<br />
<br />
# setup-apkrepos<br />
# apk update<br />
<br />
* Install the following packages required to set up LVM and LUKS:<br />
<br />
# apk add haveged lvm2 cryptsetup e2fsprogs syslinux<br />
<br />
: Optionally, you can install a different editor, such as <code>nano</code>, to edit files in later steps if you do not want to use VI.<br />
<br />
* Optionally, start the <code>haveged</code> service for unpredictable random numbers used for encryption:<br />
<br />
# rc-service haveged start<br />
<br />
<br />
<br />
== Creating the Partition Layout ==<br />
<br />
Linux requires an unencrypted <code>/boot/</code> partition to boot. You can assign the remaining space for the encrypted LVM physical volume (PV).<br />
<br />
* Start the <code>fdisk</code> utility to set up partitions:<br />
<br />
# fdisk /dev/vda<br />
<br />
:* Create the <code>/boot/</code> partition:<br />
::* Enter <code>n</code> &rarr; <code>p</code> &rarr; <code>1</code> &rarr; <code>1</code> &rarr; <code>100m</code> to create a new 100 MB primary partition.<br />
<br />
:* Set the <code>/boot/</code> partition active:<br />
::* Enter <code>a</code> &rarr; <code>1</code>.<br />
<br />
:* Create the LVM PV partition:<br />
::* Enter <code>n</code> &rarr; <code>p</code> &rarr; <code>2</code> to start creating the next partition. Press <code>Enter</code> to select the default start cylinder. Enter the size of partition. For example, <code>512m</code> for 512 MB or <code>5g</code> for 5 GB. Alternatively press <code>Enter</code> to set the maximum available size.<br />
<br />
:* Set the partition type for the LVM PV:<br />
::* Enter <code>t</code> &rarr; <code>2</code> &rarr; <code>8e</code><br />
<br />
:* To verify the settings, press <code>p</code>. The output shows, for example:<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/vda1 * 1 100 50368+ 83 Linux<br />
/dev/vda2 101 10402 5192208 8e Linux LVM<br />
<br />
* Press <code>w</code> to save the changes.<br />
<br />
* Optionally, wipe the LVM PV partition with random values:<br />
<br />
# haveged -n 0 | dd of=/dev/vda2<br />
<br />
: Depending on the size of the partition, this process can take several minutes to hours.<br />
<br />
<br />
<br />
== Encrypting the LVM Physical Volume Partition == <br />
<br />
* To encrypt the partition which will later contain the LVM PV:<br />
<br />
# cryptsetup luksFormat /dev/vda2<br />
<br />
:{{Note|Alpine Linux uses the <code>en-us</code> keyboard mapping when prompting for the password to encrypt the partition at boot time. If you changed the keyboard map in the temporary environment, the password you enter during encrypting the partition in this step, may not match the password you will enter during the system boots.}}<br />
: If you prefer setting an individual hashing algorithm and hashing schema:<br />
:* To run a benchmark:<br />
<br />
# cryptsetup benchmark<br />
<br />
:* To encrypt the partition using individual settings, enter, for example:<br />
<br />
# cryptsetup -v -c serpent-xts-plain64 -s 512 --hash whirlpool --iter-time 5000 --use-random luksFormat /dev/vda2<br />
<br />
<br />
<br />
== Creating the Logical Volumes and File Systems ==<br />
<br />
* Open the LUKS partition:<br />
<br />
# cryptsetup open --type luks /dev/vda2 lvmcrypt<br />
<br />
* Create the PV on <code>/dev/vda</code>:<br />
<br />
# pvcreate /dev/mapper/lvmcrypt<br />
<br />
* Create the <code>vg0</code> LVM VG in the <code>/dev/mapper/lvmcrypt</code> PV:<br />
<br />
# vgcreate vg0 /dev/mapper/lvmcrypt<br />
<br />
* Create the LVs:<br />
<br />
: In the following you will create a LV for the root partition. However, you can use the same command with a different LV name to create further LVs for other mount points you want to create.<br />
<br />
:* To create a 2 GB LV named <code>root</code> in the <code>vg0</code> VG:<br />
<br />
# lvcreate -L 2G vg0 -n root<br />
<br />
: Create a 512 MB swap LV:<br />
<br />
# lvcreate -L 512M vg0 -n swap<br />
<br />
* The LVs created in the previous steps are automatically marked active. To verify, enter:<br />
<br />
# lvscan<br />
<br />
: Format the <code>root</code> LV using the ext4 file system:<br />
<br />
# mkfs.ext4 /dev/vg0/root<br />
<br />
: If you created further LVs in the previous step, create the file systems on them using the same command with the path to the LV.<br />
<br />
* Format the swap LV:<br />
<br />
# mkswap /dev/vg0/swap<br />
<br />
* Format the <code>/dev/vda1</code> device for the <code>/boot/</code> partition using the ext4 file system:<br />
<br />
# mkfs.ext4 /dev/vda1<br />
<br />
<br />
<br />
== Mounting the File Systems ==<br />
<br />
Before you can install Alpine Linux, you must mount the partitions and LVs:<br />
<br />
* Mount the root LV to the <code>/mnt/</code> directory:<br />
<br />
# mount -t ext4 /dev/vg0/root /mnt/<br />
<br />
* Create <code>/mnt/boot/</code> directory and mount the <code>/dev/vda1</code> partition in this directory:<br />
<br />
# mkdir /mnt/boot/<br />
# mount -t ext4 /dev/vda1 /mnt/boot/<br />
<br />
: If you created further partitions or LVs, create the mount points within the <code>/mnt/</code> directory and mount the devices.<br />
<br />
== Installing Alpine Linux ==<br />
<br />
In this step you will install Alpine Linux in the <code>/mnt/</code> directory, which contains the mounted file system structure:<br />
<br />
* Install Alpine Linux:<br />
<br />
# setup-disk -m sys /mnt/<br />
<br />
: The installer downloads the latest packages to install the base installation. Additionally, the installer automatically creates the entries for the mount points in the <code>fstab</code> file, which are currently mounted in the <code>/mnt/</code> directory.<br />
<br />
: {{Note|The automatic writing of the master boot record (MBR) fails in this step. You will write the MBR later manually to the disk.}}<br />
<br />
* To enable the operating system to decrypt the PV at boot time, create the <code>/mnt/etc/crypttab</code> file. Enter the following line into the file to decrypt the <code>/dev/vda2</code> partition using the <code>luks</code> module and map it to the <code>lvmcrypt</code> name:<br />
<br />
lvmcrypt /dev/vda2 none luks<br />
<br />
* The swap LV is not automatically added to the <code>fstab</code> file. To add it manually, add the following line to the <code>/mnt/etc/fstab</code> file:<br />
<br />
/dev/vg0/swap swap swap defaults 0 0<br />
<br />
* Edit the <code>/mnt/etc/mkinitfs/mkinitfs.conf</code> file and append the <code>cryptsetup</code> module to the <code>features</code> parameter:<br />
<br />
features="ata base ide scsi usb virtio ext4 lvm <u>cryptsetup</u>"<br />
<br />
* Rebuild the initial RAM disk:<br />
<br />
# mkinitfs -c /mnt/etc/mkinitfs/mkinitfs.conf -b /mnt/ $(ls /mnt/lib/modules/)<br />
<br />
: The command uses the settings from the <code>mkinitfs.conf</code> file set in the <code>-c</code> parameter to generate the RAM disk. The command is executed in the <code>/mnt/</code> directory and the RAM disk is generated using the modules for the installed kernel. Without setting the kernel version using the <code>$(ls /mnt/lib/modules/</code>) option, <code>mkinitfs</code> tries to generate the RAM disk using the kernel version installed in the temporary environment, which can differ from the latest one installed by the <code>setup-disk</code> utility.<br />
<br />
* Edit the <code>/mnt/etc/update-extlinux.conf</code> file and append the following kernel options to the <code>default_kernel_opts</code> parameter:<br />
<br />
default_kernel_opts="... <u>cryptroot=/dev/vda2 cryptdm=lvmcrypt</u>"<br />
<br />
: The <code>cryptroot</code> parameter sets the name of the device that contains the root file system. The <code>cryptdm</code> parameter sets the name of the mapping previously set in the <code>crypttab</code> file.<br />
<br />
* Because the <code>update-extlinux</code> utility operators only on the <code>/boot/</code> directory, temporarily change the root to the <code>/mnt/</code> directory and update the boot loader configuration:<br />
<br />
# chroot /mnt/<br />
# update-extlinux<br />
# exit<br />
<br />
: Ignore the errors the <code>update-extlinux</code> utility displays.<br />
<br />
* Write the MBR to the <code>/dev/vda</code> device:<br />
<br />
# dd bs=440 count=1 conv=notrunc if=/mnt/usr/share/syslinux/mbr.bin of=/dev/vda<br />
<br />
== Unmounting the Volumes and Partitions ==<br />
<br />
* Umount <code>/mnt/boot/</code> and <code>/mnt/</code>:<br />
<br />
# umount /mnt/boot/<br />
# umount /mnt/<br />
<br />
: {{Note|If you mounted further partitions or LVs below <code>/mnt/</code>, you must first unmount all of them before you can unmount <code>/mnt/</code>.}}<br />
<br />
* Disable the swap partition:<br />
<br />
# swapoff -a<br />
<br />
* Deactivate the VG:<br />
<br />
# vgchange -a n<br />
<br />
* Close the <code>lvmcrypt</code> device:<br />
<br />
# cryptsetup luksClose lvmcrypt<br />
<br />
* Reboot the system:<br />
<br />
# reboot<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
== General Procedure ==<br />
<br />
In case your system fails to boot, you can verify the settings and fix incorrect configurations:<br />
<br />
* [[#Preparing_the_Temporary_Installation_Environment|Prepare the temporary installation environment]]<br />
<br />
* Activate the VGs:<br />
<br />
# vgchange -a y<br />
<br />
* [[#Mounting_the_File_Systems|Mount the file systems]]<br />
<br />
* Verify that you run the steps described in the [[#Installing_Alpine_Linux|Installing Alpine Linux]] section correctly. Update the configuration if necessary.<br />
<br />
* [[#Unmounting_the_Volumes_and_Partitions|Unmount the volumes and partitions]]<br />
<br />
= Hardening =<br />
<br />
* To harden, you should disable DMA[https://old.iseclab.org/papers/acsac2012dma.pdf] and install a hardened version of AES (TRESOR[https://www1.informatik.uni-erlangen.de/tresor] or LoopAmnesia[http://moongate.ydns.eu/amnesia.html]) since by default cryptsetup with luks uses AES by default.<br />
<br />
[[Category:Storage]]<br />
[[Category:Security]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=LVM_on_LUKS&diff=15168LVM on LUKS2018-03-14T21:21:34Z<p>Orson Teodoro: put hardening section</p>
<hr />
<div>= Introduction =<br />
<br />
This documentation describes how to set up Alpine Linux using a logical volume (LV), that is installed in an encrypted partition. To encrypt the partition the logical volume manager (LVM) the volume group (VG) is installed in, the Device Mapper crypt (dm-crypt) module and Linux Unified Key Setup (LUKS) is used.<br />
<br />
Note that you must install the <code>/boot/</code> directory on an unecrypted partition to boot correctly.<br />
<br />
<br />
== Hard Disk Device Name ==<br />
<br />
The following documentation uses the <code>vda</code> device as installation destination. If your environment uses a different device name for your hard disk, use the corresponding device names in the examples.<br />
<br />
<br />
<br />
<br />
<br />
= Setting up Alpine Linux Using LVM on Top of a LUKS Partition =<br />
<br />
To install Alpine Linux in logical volumes running on top of a LUKS encrypted partition, you cannot use the [[Installation|official installation]] procedure. The installation requires several manual steps you must run in the Alpine Linux Live CD environment.<br />
<br />
<br />
<br />
== Preparing the Temporary Installation Environment ==<br />
<br />
Before you begin to install Alpine Linux, prepare the temporary environment:<br />
<br />
{{Note|All settings in this section apply only to the temporary environment and not to the later installed Alpine Linux on your hard disk.}}<br />
<br />
* Boot the latest Alpine Linux Installation CD.<br />
<br />
* At the login prompt, use the <code>root</code> user without password to log in.<br />
<br />
* Optionally, set the keyboard language:<br />
<br />
# setup-keymap<br />
<br />
: The default keyboard mapping is <code>us-us</code><br />
<br />
* Configure the network interface:<br />
<br />
# setup-interfaces<br />
<br />
: If you set a static IP address, additionally configure DNS be able to resolve host names:<br />
<br />
# setup-dns<br />
<br />
* Enable the network interface. For example:<br />
<br />
# ifup eth0<br />
<br />
* Set an apk repository and update the cache:<br />
<br />
# setup-apkrepos<br />
# apk update<br />
<br />
* Install the following packages required to set up LVM and LUKS:<br />
<br />
# apk add haveged lvm2 cryptsetup e2fsprogs syslinux<br />
<br />
: Optionally, you can install a different editor, such as <code>nano</code>, to edit files in later steps if you do not want to use VI.<br />
<br />
* Optionally, start the <code>haveged</code> service for unpredictable random numbers used for encryption:<br />
<br />
# rc-service haveged start<br />
<br />
<br />
<br />
== Creating the Partition Layout ==<br />
<br />
Linux requires an unencrypted <code>/boot/</code> partition to boot. You can assign the remaining space for the encrypted LVM physical volume (PV).<br />
<br />
* Start the <code>fdisk</code> utility to set up partitions:<br />
<br />
# fdisk /dev/vda<br />
<br />
:* Create the <code>/boot/</code> partition:<br />
::* Enter <code>n</code> &rarr; <code>p</code> &rarr; <code>1</code> &rarr; <code>1</code> &rarr; <code>100m</code> to create a new 100 MB primary partition.<br />
<br />
:* Set the <code>/boot/</code> partition active:<br />
::* Enter <code>a</code> &rarr; <code>1</code>.<br />
<br />
:* Create the LVM PV partition:<br />
::* Enter <code>n</code> &rarr; <code>p</code> &rarr; <code>2</code> to start creating the next partition. Press <code>Enter</code> to select the default start cylinder. Enter the size of partition. For example, <code>512m</code> for 512 MB or <code>5g</code> for 5 GB. Alternatively press <code>Enter</code> to set the maximum available size.<br />
<br />
:* Set the partition type for the LVM PV:<br />
::* Enter <code>t</code> &rarr; <code>2</code> &rarr; <code>8e</code><br />
<br />
:* To verify the settings, press <code>p</code>. The output shows, for example:<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/vda1 * 1 100 50368+ 83 Linux<br />
/dev/vda2 101 10402 5192208 8e Linux LVM<br />
<br />
* Press <code>w</code> to save the changes.<br />
<br />
* Optionally, wipe the LVM PV partition with random values:<br />
<br />
# haveged -n 0 | dd of=/dev/vda2<br />
<br />
: Depending on the size of the partition, this process can take several minutes to hours.<br />
<br />
<br />
<br />
== Encrypting the LVM Physical Volume Partition == <br />
<br />
* To encrypt the partition which will later contain the LVM PV:<br />
<br />
# cryptsetup luksFormat /dev/vda2<br />
<br />
:{{Note|Alpine Linux uses the <code>en-us</code> keyboard mapping when prompting for the password to encrypt the partition at boot time. If you changed the keyboard map in the temporary environment, the password you enter during encrypting the partition in this step, may not match the password you will enter during the system boots.}}<br />
: If you prefer setting an individual hashing algorithm and hashing schema:<br />
:* To run a benchmark:<br />
<br />
# cryptsetup benchmark<br />
<br />
:* To encrypt the partition using individual settings, enter, for example:<br />
<br />
# cryptsetup -v -c serpent-xts-plain64 -s 512 --hash whirlpool --iter-time 5000 --use-random luksFormat /dev/vda2<br />
<br />
<br />
<br />
== Creating the Logical Volumes and File Systems ==<br />
<br />
* Open the LUKS partition:<br />
<br />
# cryptsetup open --type luks /dev/vda2 lvmcrypt<br />
<br />
* Create the PV on <code>/dev/vda</code>:<br />
<br />
# pvcreate /dev/mapper/lvmcrypt<br />
<br />
* Create the <code>vg0</code> LVM VG in the <code>/dev/mapper/lvmcrypt</code> PV:<br />
<br />
# vgcreate vg0 /dev/mapper/lvmcrypt<br />
<br />
* Create the LVs:<br />
<br />
: In the following you will create a LV for the root partition. However, you can use the same command with a different LV name to create further LVs for other mount points you want to create.<br />
<br />
:* To create a 2 GB LV named <code>root</code> in the <code>vg0</code> VG:<br />
<br />
# lvcreate -L 2G vg0 -n root<br />
<br />
: Create a 512 MB swap LV:<br />
<br />
# lvcreate -L 512M vg0 -n swap<br />
<br />
* The LVs created in the previous steps are automatically marked active. To verify, enter:<br />
<br />
# lvscan<br />
<br />
: Format the <code>root</code> LV using the ext4 file system:<br />
<br />
# mkfs.ext4 /dev/vg0/root<br />
<br />
: If you created further LVs in the previous step, create the file systems on them using the same command with the path to the LV.<br />
<br />
* Format the swap LV:<br />
<br />
# mkswap /dev/vg0/swap<br />
<br />
* Format the <code>/dev/vda1</code> device for the <code>/boot/</code> partition using the ext4 file system:<br />
<br />
# mkfs.ext4 /dev/vda1<br />
<br />
<br />
<br />
== Mounting the File Systems ==<br />
<br />
Before you can install Alpine Linux, you must mount the partitions and LVs:<br />
<br />
* Mount the root LV to the <code>/mnt/</code> directory:<br />
<br />
# mount -t ext4 /dev/vg0/root /mnt/<br />
<br />
* Create <code>/mnt/boot/</code> directory and mount the <code>/dev/vda1</code> partition in this directory:<br />
<br />
# mkdir /mnt/boot/<br />
# mount -t ext4 /dev/vda1 /mnt/boot/<br />
<br />
: If you created further partitions or LVs, create the mount points within the <code>/mnt/</code> directory and mount the devices.<br />
<br />
== Installing Alpine Linux ==<br />
<br />
In this step you will install Alpine Linux in the <code>/mnt/</code> directory, which contains the mounted file system structure:<br />
<br />
* Install Alpine Linux:<br />
<br />
# setup-disk -m sys /mnt/<br />
<br />
: The installer downloads the latest packages to install the base installation. Additionally, the installer automatically creates the entries for the mount points in the <code>fstab</code> file, which are currently mounted in the <code>/mnt/</code> directory.<br />
<br />
: {{Note|The automatic writing of the master boot record (MBR) fails in this step. You will write the MBR later manually to the disk.}}<br />
<br />
* To enable the operating system to decrypt the PV at boot time, create the <code>/mnt/etc/crypttab</code> file. Enter the following line into the file to decrypt the <code>/dev/vda2</code> partition using the <code>luks</code> module and map it to the <code>lvmcrypt</code> name:<br />
<br />
lvmcrypt /dev/vda2 none luks<br />
<br />
* The swap LV is not automatically added to the <code>fstab</code> file. To add it manually, add the following line to the <code>/mnt/etc/fstab</code> file:<br />
<br />
/dev/vg0/swap swap swap defaults 0 0<br />
<br />
* Edit the <code>/mnt/etc/mkinitfs/mkinitfs.conf</code> file and append the <code>cryptsetup</code> module to the <code>features</code> parameter:<br />
<br />
features="ata base ide scsi usb virtio ext4 lvm <u>cryptsetup</u>"<br />
<br />
* Rebuild the initial RAM disk:<br />
<br />
# mkinitfs -c /mnt/etc/mkinitfs/mkinitfs.conf -b /mnt/ $(ls /mnt/lib/modules/)<br />
<br />
: The command uses the settings from the <code>mkinitfs.conf</code> file set in the <code>-c</code> parameter to generate the RAM disk. The command is executed in the <code>/mnt/</code> directory and the RAM disk is generated using the modules for the installed kernel. Without setting the kernel version using the <code>$(ls /mnt/lib/modules/</code>) option, <code>mkinitfs</code> tries to generate the RAM disk using the kernel version installed in the temporary environment, which can differ from the latest one installed by the <code>setup-disk</code> utility.<br />
<br />
* Edit the <code>/mnt/etc/update-extlinux.conf</code> file and append the following kernel options to the <code>default_kernel_opts</code> parameter:<br />
<br />
default_kernel_opts="... <u>cryptroot=/dev/vda2 cryptdm=lvmcrypt</u>"<br />
<br />
: The <code>cryptroot</code> parameter sets the name of the device that contains the root file system. The <code>cryptdm</code> parameter sets the name of the mapping previously set in the <code>crypttab</code> file.<br />
<br />
* Because the <code>update-extlinux</code> utility operators only on the <code>/boot/</code> directory, temporarily change the root to the <code>/mnt/</code> directory and update the boot loader configuration:<br />
<br />
# chroot /mnt/<br />
# update-extlinux<br />
# exit<br />
<br />
: Ignore the errors the <code>update-extlinux</code> utility displays.<br />
<br />
* Write the MBR to the <code>/dev/vda</code> device:<br />
<br />
# dd bs=440 count=1 conv=notrunc if=/mnt/usr/share/syslinux/mbr.bin of=/dev/vda<br />
<br />
== Unmounting the Volumes and Partitions ==<br />
<br />
* Umount <code>/mnt/boot/</code> and <code>/mnt/</code>:<br />
<br />
# umount /mnt/boot/<br />
# umount /mnt/<br />
<br />
: {{Note|If you mounted further partitions or LVs below <code>/mnt/</code>, you must first unmount all of them before you can unmount <code>/mnt/</code>.}}<br />
<br />
* Disable the swap partition:<br />
<br />
# swapoff -a<br />
<br />
* Deactivate the VG:<br />
<br />
# vgchange -a n<br />
<br />
* Close the <code>lvmcrypt</code> device:<br />
<br />
# cryptsetup luksClose lvmcrypt<br />
<br />
* Reboot the system:<br />
<br />
# reboot<br />
<br />
<br />
<br />
<br />
<br />
= Troubleshooting =<br />
<br />
== General Procedure ==<br />
<br />
In case your system fails to boot, you can verify the settings and fix incorrect configurations:<br />
<br />
* [[#Preparing_the_Temporary_Installation_Environment|Prepare the temporary installation environment]]<br />
<br />
* Activate the VGs:<br />
<br />
# vgchange -a y<br />
<br />
* [[#Mounting_the_File_Systems|Mount the file systems]]<br />
<br />
* Verify that you run the steps described in the [[#Installing_Alpine_Linux|Installing Alpine Linux]] section correctly. Update the configuration if necessary.<br />
<br />
* [[#Unmounting_the_Volumes_and_Partitions|Unmount the volumes and partitions]]<br />
<br />
= Hardening =<br />
<br />
* To harden, you should disable DMA[https://old.iseclab.org/papers/acsac2012dma.pdf] and install a hardened version of AES (TRESOR[https://www1.informatik.uni-erlangen.de/tresor] or LoopAmnesia[http://moongate.ydns.eu/amnesia.html]) since by default cryptsetup uses AES by default.<br />
<br />
[[Category:Storage]]<br />
[[Category:Security]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15167Setting up a laptop2018-03-14T20:48:45Z<p>Orson Teodoro: /* Important notes */ confirm</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
[[Category:Installation]]</div>Orson Teodorohttps://wiki.alpinelinux.org/w/index.php?title=Setting_up_a_laptop&diff=15166Setting up a laptop2018-03-14T20:06:22Z<p>Orson Teodoro: /* Important notes */ put mitigation recommendation</p>
<hr />
<div>{{Draft}}<br />
<br />
This guide is about a project to create a '''secured laptop'''. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.<br />
<br />
== Guide features ==<br />
<br />
*Deniable full disk encryption<br />
*Two factor authentication (physical (USB key), mind) <br />
*Encrypted swap and hibernation<br />
*Encrypted home on top of encrypted drive<br />
*Memory sanitation<br />
*Dynamic power modes<br />
*Feature keys support<br />
<br />
== Rubberhose Attack ==<br />
<br />
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article]. We try to present [https://en.wikipedia.org/wiki/Deniable_encryption deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.<br />
<br />
== Why full disk? ==<br />
<br />
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.<br />
<br />
But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.<br />
<br />
If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.<br />
<br />
== Starting at the beginning ==<br />
<br />
Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.<br />
<br />
You will then install Alpine using the steps:<br />
<br />
First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:<br />
<br />
setup-alpine<br />
<br />
Then, you need to install some tools into RAM temporarly:<br />
apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano<br />
<br />
== Randomizing the drive with pseudorandom urandom entropy ==<br />
<br />
The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.<br />
<br />
You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article]. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.<br />
<br />
To list the drives on the system do <code>fdisk -l</code>. <br />
<br />
'''IMPORTANT: make sure you wipe the right specific drive.'''<br />
<br />
To wipe the disk with random entropy do:<br />
<br />
dd if=/dev/urandom of=/dev/sda<br />
<br />
== Creating GPG keys ==<br />
<br />
'''As of this time, Alpine's mkinitfs does only one factor authentication with passphrase.''' You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.<br />
<br />
After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.<br />
<br />
If you are using x, you need to do <code>sudo apk add pinentry-gtk</code> to display password prompt properly for the next step.<br />
<br />
To install openssl and gpg do:<br />
<br />
apk add openssl gnupg<br />
<br />
Then, to generate a key:<br />
<br />
openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5<br />
<br />
(Make sure your usb is mounted on /mnt/usb first.)<br />
<br />
The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?<br />
<br />
The first part will produce 128 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.<br />
<br />
You can replace aes above with the ones listed in <code>gpg --version</code>.<br />
<br />
There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.<br />
<br />
== Hiding the keys using steganography ==<br />
<br />
''WARNING:'' This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use <code>steghide encinfo</code> for other ciphers and modes.<br />
<br />
Fortunately, Alpine has a package for steganography called steghide. To install steghide do:<br />
<br />
apk add steghide<br />
<br />
You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.<br />
<br />
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.<br />
<br />
There are two basic commands to use with steghide embed and extract,<br />
<br />
To embed do:<br />
<br />
steghide embed -ef key.gpg -cf image.jpg<br />
<br />
To extract do:<br />
<br />
steghide extract -xf key.gpg -sf image.jpg<br />
<br />
To get a file list of files to ship out, use:<br />
<br />
apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide<br />
<br />
== Full disk encryption with with cryptsetup-luks volumes ==<br />
<br />
=== Partitioning scheme ===<br />
<br />
This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.<br />
<br />
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.<br />
<br />
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.<br />
<br />
==== Luks ====<br />
<br />
Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 3<br />
| root<br />
| /<br />
|<br />
|-<br />
| 4<br />
| rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
==== Plain dm-crypt ====<br />
<br />
Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Name<br />
!Mount point<br />
!Notes<br />
|-<br />
| 1<br />
| facade<br />
| /<br />
| (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.<br />
|-<br />
| 2<br />
| vgroot<br />
| <br />
| <br />
|-<br />
| 2_1<br />
| vgroot-root<br />
| /<br />
| <br />
|-<br />
| 2_2<br />
| vgroot-swap<br />
| <br />
| It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.<br />
|-<br />
| 2_3<br />
| vgroot-rescue<br />
| /<br />
| This should contain the Alpine image.<br />
|-<br />
|}<br />
<br />
=== Installing cryptsetup ===<br />
<br />
To install cryptsetup you need the package below<br />
<br />
apk add cryptsetup<br />
<br />
=== Choosing ciphers ===<br />
<br />
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary] If it is hardware accelerated, it will save battery life and minimize CPU usage.<br />
<br />
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].<br />
<br />
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].<br />
<br />
Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.<br />
<br />
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.<br />
<br />
If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.<br />
<br />
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]<br />
<br />
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]<br />
<br />
'''IMPORTANT: Do not use sha1 as the hashing algorithm.''' It already has already been compromised.<br />
<br />
=== Getting the available ciphers ===<br />
<br />
To check the availability of a cipher or hash function use:<br />
find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort<br />
<br />
To check if a cipher is loaded and passed its own tests use:<br />
cat /proc/crypto<br />
<br />
To test some popular ciphers and hashes do:<br />
<br />
cryptsetup benchmark<br />
<br />
The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.<br />
<br />
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128. <br />
<br />
To test if the unpopular but uncracked cipher works use sometime like:<br />
cryptsetup benchmark --cipher anubis<br />
<br />
=== General steps for cryptsetup ===<br />
<br />
==== Original method with fdisk with no plausible deniability ====<br />
<br />
In this method <code>--type luks</code> is implied which generates metadata.<br />
<br />
If you want plausible deniability for luks, you need to pass <code>--header <path></code> to all the luks commands, where <code><path></code> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from <code>openssl rand -hex 8</code>. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.<br />
<br />
You need to install cfdisk if you prefer the interactive ncurses console method:<br />
<br />
apk add cfdisk<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition<br />
| <code><nowiki>cfdisk</nowiki></code><br />
|-<br />
| 2<br />
| Create and format the luks device<br />
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code><br />
|-<br />
| 3<br />
| Open the luks device<br />
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code><br />
|-<br />
| 4<br />
| Format the decrypted drive with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/root</code><br />
|-<br />
| 5<br />
| Create the mount point<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 6<br />
| Mount the root partition<br />
| <code>mount /dev/mapper/root /mnt/root</code><br />
|-<br />
| 7<br />
| Create swap<br />
| cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2 <br />
|-<br />
| 8<br />
| Use swap<br />
| mkswap /dev/mapper/swap && swapon /dev/mapper/swap<br />
|}<br />
<br />
==== Improved method with plausible deniability ====<br />
<br />
This method requires lvm2. To install:<br />
<br />
apk add lvm2<br />
<br />
{|| cellpadding="5" border="1" class="wikitable"<br />
!#<br />
!Step<br />
!Command<br />
|-<br />
| 1<br />
| Open the ''plain dm-crypt'' device generating no metadata<br />
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code><br />
|-<br />
| 2<br />
| Physical volume create with LVM<br />
| <code><nowiki>pvcreate /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 3<br />
| Volume group create with LVM<br />
| <code><nowiki>vgcreate vgroot /dev/mapper/pvroot</nowiki></code><br />
|-<br />
| 4<br />
| Logical volume create the swap volume with LVM<br />
| <code><nowiki>lvcreate -L 4G vgroot -n swap</nowiki></code><br />
|-<br />
| 5<br />
| Logical volume create the root volume with LVM<br />
| <code><nowiki>lvcreate -L 2T vgroot -n root</nowiki></code><br />
|-<br />
| 6<br />
| Logical volume create the rescue volume with LVM<br />
| <code><nowiki>lvcreate -L 110M vgroot -n rescue</nowiki></code><br />
|-<br />
| 7<br />
| Format the root volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-root</code><br />
|-<br />
| 8<br />
| Format the swap volume and activate it<br />
| <code>mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap</code><br />
|-<br />
| 9<br />
| Format the rescue volume with filesystem<br />
| <code>mkfs.ext4 /dev/mapper/vgroot-rescue</code><br />
|-<br />
| 10<br />
| Create mount point for root volume<br />
| <code>mkdir -p /mnt/root</code><br />
|-<br />
| 11<br />
| Mount the root volume<br />
| <code>mount /dev/mapper/vgroot-root /mnt/root</code><br />
|-<br />
|}<br />
<br />
=== Configuring OpenRC dmcrypt and setting up fstab ===<br />
<br />
You need to tell OpenRC init scripts to decrypt the volumes. See <code>/etc/conf.d/dmcrypt</code>.<br />
<br />
You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:<br />
<br />
rc-update add dmcrypt boot<br />
<br />
==== /etc/init.d/dmcrypt ====<br />
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.<br />
<br />
For ''luks'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root may not be necessary since it is already mounted.<br />
target=root<br />
source='/dev/sda1'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
</nowiki>}}<br />
<br />
For ''plain dm-crypt'':<br />
<br />
{{Cat|/etc/conf.d/dmcrypt|<nowiki><br />
# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing.<br />
target=root<br />
source='/dev/sda'<br />
key='/mnt/usb/2a667ec72774b0d5'<br />
options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256'<br />
<br />
swap=swap<br />
source='/dev/sda2'<br />
key='/mnt/usb/59022506d9f4a714'<br />
pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'<br />
</nowiki>}}<br />
<br />
dm-crypt will just mount the encrypted ''plain dm-crypt'' drive or the ''luks'' partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.<br />
<br />
==== /etc/fstab ====<br />
<br />
To mount ''plain dm-crypt'' device with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
To mount ''lvm'' volumes with fstab:<br />
<br />
{{Cat|/etc/fstab|<br />
/dev/sdb /boot ext4 defaults 0 0<br />
/dev/mapper/vgroot-root / ext4 defaults 0 1<br />
/dev/mapper/vgroot-swap none swap sw 0 0<br />
}}<br />
<br />
=== How to recover from a bad setup ===<br />
<br />
Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the ''plain dm-crypt'' drive or the ''luks'' drive and then remount everything back.<br />
<br />
To recover from ''luks'':<br />
cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/root /mnt/root<br />
<br />
To recover from the ''plain dm-crypt'':<br />
cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root<br />
vgchange -ay vgroot<br />
lvchange -ay vgroot/root<br />
mkdir -p /mnt/root<br />
mount /dev/mapper/vgroot-swap /mnt/root<br />
<br />
== Next step: Full blown Alpine installation ==<br />
<br />
We will setup the /mnt/root encrypted partition:<br />
apk add --root=/mnt/root --initdb $(cat /etc/apk/world)<br />
<br />
Then, enable edge repositories in both files including community and testing:<br />
nano /etc/apk/repositories /mnt/root/etc/apk/repositories<br />
<br />
Then, copy the necessary files:<br />
cp /etc/resolv.conf /mnt/root/etc<br />
<br />
Then, install the basic utils:<br />
apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant<br />
apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi<br />
apk add --root=/mnt/root sudo nano<br />
apk add --root=/mnt/root linux-hardened<br />
<br />
Then, you need to mount your usb on to /boot:<br />
mount /dev/sdb /boot<br />
<br />
Edit grub:<br />
nano /boot/grub/grub.cfg<br />
<br />
Then, install grub on the usb:<br />
grub-install --force /dev/sdb<br />
<br />
Then, prepare chroot:<br />
mount --bind /dev /mnt/root/dev<br />
mount --bind /sys /mnt/root/sys<br />
cp /etc/reslov.conf /mnt/root/etc<br />
<br />
Then, chroot:<br />
chroot /mnt/root /bin/sh<br />
<br />
Set the root administrator password:<br />
passwd<br />
<br />
The root password should be very difficult to deter you from using it and force you to use sudo<br />
<br />
Edit sudo so that wheel group has administrative :<br />
EDITOR=nano visudo<br />
<br />
Set:<br />
## Uncomment to allow members of group wheel to execute any command <br />
%wheel ALL=(ALL) ALL <br />
<br />
Then, add wheel (administrator) user:<br />
useradd -m myname<br />
usermod -a -G video,audio,wheel myname<br />
<br />
log in that user:<br />
su myname<br />
<br />
Then, update and upgrade it<br />
sudo apk update<br />
sudo apk upgrade<br />
<br />
Then, setup xorg:<br />
sudo setup-xorg-base<br />
sudo apk search xf86-video | sort<br />
# pick your video driver<br />
sudo apk add xf86-video-adi<br />
# pick your opengl driver<br />
sudo apk search mesa-dri* | sort<br />
sudo apk add mesa-dri-ati <br />
<br />
Then, keep piling on:<br />
sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat<br />
sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation<br />
sudo apk add xf86-input-mouse xf86-input-keyboard<br />
<br />
Then, set the desktop:<br />
nano .xinitrc<br />
<br />
Put both but comment with a # one of them if you don't want it,<br />
#while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &<br />
#exec dwm<br />
exec xfce4-session<br />
<br />
For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.<br />
<br />
sync<br />
sudo reboot<br />
<br />
== Hacking mkinitfs to support cryptsetup with GPG keys ==<br />
<br />
This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical.<br />
<br />
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.<br />
<br />
Here is the steps required so that the facade initscripts and dependencies are free from encryption.<br />
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.<br />
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.<br />
<br />
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:<br />
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.<br />
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.<br />
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.<br />
<br />
You need to create a custom init continuation script:<br />
* Your initscript should drop into single mode which you will mount the encrypted path manually. <br />
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.<br />
* You will run the custom init continuation script manually.<br />
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.<br />
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.<br />
<br />
You need to generate the final mkinitfs.<br />
First you need the kernelversion to pass into mkinitfs. To obtain that information do <code>ls /lib/modules</code> which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:<br />
<br />
sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion<br />
<br />
The $HOMEDIR should be replaced with the full path if you are not root.<br />
<br />
== Install the bootloader in the USB thumb drive ==<br />
<br />
To install grub, you need to install grub on the ramdisk first on the host. <br />
<br />
apk add grub<br />
<br />
To get a list of partitions<br />
<br />
fdisk -l<br />
<br />
Mount the boot partition in /boot<br />
<br />
mount /dev/sdb /boot<br />
<br />
Make changes to grub's configuration <br />
<br />
nano /boot/grub/grub.cfg<br />
<br />
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.''' <br />
<br />
The steps here below assumes that these custom initramfs features have been implemented. <br />
<br />
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.<br />
<br />
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.<br />
<br />
The entry should look like:<br />
<br />
For 'luks'<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
For 'plain dm-crypt':<br />
<br />
The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.<br />
<br />
{{cat|/boot/grub/grub.cfg|<nowiki><br />
default=0<br />
timeout=0<br />
<br />
menuentry 'Windows 10' {<br />
set root=(hd0,2)<br />
chainloader +1<br />
}<br />
<br />
menuentry 'Alpine Linux' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root<br />
initrd /initramfs-hardened<br />
}<br />
<br />
menuentry 'Alpine Linux (Rescue)' {<br />
set root=(hd1,1)<br />
linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue<br />
initrd /initramfs-hardened<br />
}<br />
<br />
if keystatus; then<br />
if keystatus --ctrl; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [https://github.com/lemenkov/grub2/blob/master/grub-core/commands/keystatus.c]. Ideally, it should be not so obvious or accessible for the attacker.<br />
<br />
The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.<br />
<br />
For the modules parameter, you need to add your crypto modules.<br />
Use <code>find /lib/modules/ -name "*aes*"</code> where aes is the basename for your cipher or hash algorithm<br />
Use <code>blkid</code> to obtain the UUID of your device<br />
<br />
Install it to your USB thumb drive<br />
<br />
grub-install /dev/sdb<br />
<br />
== Home mounting with eCryptfs ==<br />
<br />
We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.<br />
<br />
To install ecryptfs-utils:<br />
<br />
sudo apk add ecryptfs-utils<br />
<br />
This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.<br />
<br />
You need to use the pam_ecryptfs PAM module.<br />
<br />
== Locking it down ==<br />
<br />
Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.<br />
<br />
=== physlock ===<br />
<br />
This will auto lock the tty and when you return will prompt for password.<br />
<br />
To install physlock:<br />
<br />
sudo apk add physlock<br />
<br />
It is currently bugged. See [https://bugs.alpinelinux.org/issues/3282]. physlock likely doesn't do two-factor authentication but it should.<br />
<br />
You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.<br />
<br />
=== xscreensaver ===<br />
<br />
This will lock you out of xserver<br />
<br />
To install xscreensaver:<br />
<br />
sudo apk add xscreensaver<br />
<br />
=== USB key udev rule ===<br />
<br />
You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.<br />
<br />
To find out the details of your USB do:<br />
<br />
udevadm monitor --udev -p<br />
<br />
The output should look like:<br />
<br />
<pre><br />
UDEV [181762.722853] add /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)<br />
ACTION=add<br />
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4<br />
DEVNAME=/dev/sdc<br />
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc<br />
DEVTYPE=disk<br />
ID_BUS=usb<br />
ID_FS_TYPE=vfat<br />
ID_FS_USAGE=filesystem<br />
ID_FS_UUID=5A96-03E4<br />
ID_FS_UUID_ENC=5A96-03E4<br />
ID_FS_VERSION=FAT32<br />
ID_INSTANCE=0:0<br />
ID_MODEL=MSFT_NORB<br />
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20<br />
ID_MODEL_ID=1645<br />
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0<br />
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0<br />
ID_REVISION=PMAP<br />
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0<br />
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009<br />
ID_TYPE=disk<br />
ID_USB_DRIVER=usb-storage<br />
ID_USB_INTERFACES=:080650:<br />
ID_USB_INTERFACE_NUM=00<br />
ID_VENDOR=Kingston<br />
ID_VENDOR_ENC=Kingston<br />
ID_VENDOR_ID=0951<br />
MAJOR=8<br />
MINOR=32<br />
SEQNUM=2027<br />
SUBSYSTEM=block<br />
USEC_INITIALIZED=1762722168<br />
</pre><br />
<br />
You want to extract the <code>ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009</code> or whatever is associated with your USB thumb drive.<br />
<br />
You need pm-utils for ps-suspend. So to install it do:<br />
<br />
sudo apk add pm-utils<br />
<br />
You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:<br />
<br />
{{Cat|/etc/udev/rules.d/50-usb-thumb-drive.rules|<nowiki><br />
<br />
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"<br />
<br />
</nowiki>}}<br />
<br />
== Extending battery life ==<br />
<br />
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''<br />
<br />
=== ACPI ===<br />
<br />
ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.<br />
<br />
To install ACPI do:<br />
<br />
apk add acpi<br />
<br />
The events to pay attention to are:<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
! Event<br />
! ACPI Event<br />
! What your script should do<br />
|-<br />
| lid close<br />
|<br />
| log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.<br />
|-<br />
| lid open<br />
|<br />
| lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.<br />
|-<br />
| tapped power button<br />
|<br />
| lock all ttys and suspend-to-ram<br />
|-<br />
| held power button<br />
|<br />
| hibernate<br />
|-<br />
| unplugged power<br />
|<br />
| should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.<br />
|-<br />
| plugged power<br />
|<br />
| should switch to 'performance' governor. disable hdparam spindown.<br />
|}<br />
<br />
The purpose of the power governor is to regulate the running frequency (GHz) of the processor.<br />
<br />
Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.<br />
<br />
<code>acpi_listen</code> can be used to retrieve the event name.<br />
<br />
TODO: put scripts below<br />
<br />
=== Adjusting the backlight dynamically ===<br />
<br />
The backlight may be controlled using sysfs. The setting is a descendant of <code>/sys/class/backlight/</code>. The feature may allow you to echo a value to it. Use trial and error to discover the values.<br />
<br />
The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.<br />
<br />
=== hdparm ===<br />
<br />
To install hdparam do:<br />
<br />
sudo apk add hdparm<br />
<br />
The settings that laptop-mode-tools messes with is the <code>-S</code> or the spindown timeout. It was also hinted that acoustic setting <code>-M</code> is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.<br />
<br />
Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.<br />
<br />
=== laptop-mode-tools ===<br />
<br />
This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.<br />
<br />
=== cpufreqd ===<br />
<br />
This is a useful daemon for regulating power.<br />
<br />
To install cpufreqd do:<br />
<br />
sudo apk add cpufreqd<br />
<br />
Make sure you add the service:<br />
<br />
sudo rc-update add cpufreqd<br />
<br />
=== LCD screen refresh rate ===<br />
<br />
The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.<br />
<br />
== Hacking the kernel ==<br />
<br />
You should refer to the [[Custom Kernel]] page for details.<br />
<br />
== Hibernation ==<br />
<br />
See [[Custom_Kernel#Hibernation_to_prevent_data_loss|Hibernation to prevent data loss]].<br />
<br />
== WiFi management ==<br />
<br />
Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.<br />
<br />
To install NetworkManager do:<br />
<br />
sudo apk add networkmanager<br />
<br />
To find WiFi access points use the <code>nmtui</code> ncurses interface.<br />
<br />
You also need other programs so install them as well:<br />
<br />
apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils<br />
<br />
What these programs do:<br />
<br />
* wpa-supplicant -- for WPA encryption<br />
* dhcpcd -- for getting a dynamic IP address<br />
* chrony -- for fixing the time with the atomic clock<br />
* wireless-tools -- for additional information<br />
* macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)<br />
* iputils -- for the ping command (optional)<br />
<br />
You also need to add those services:<br />
<br />
rc-update add chrony<br />
rc-update add wpa-supplicant<br />
rc-update add dhcpcd<br />
rc-update add networkmanager<br />
<br />
To start the services manually (or just reboot):<br />
<br />
/etc/init.d/chrony start<br />
/etc/init.d/wpa-supplicant start<br />
/etc/init.d/dhcpcd start<br />
/etc/init.d networkmanager start<br />
<br />
== Additional tools ==<br />
<br />
=== actkbd ===<br />
<br />
To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.<br />
<br />
If your laptop contains a brightness key, you want to set that up with this program. See also [[Setting_up_a_laptop#Adjusting_the_backlight_dynamically | Adjusting the backlight dynamically]].<br />
<br />
=== secure-delete ===<br />
<br />
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows?<br />
<br />
To install secure-delete do:<br />
<br />
sudo apk add secure-delete<br />
<br />
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]<br />
<br />
Close all important programs then call smem.<br />
<br />
You call smem in your shutdown script or auto-logoff script.<br />
<br />
You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.<br />
<br />
You may want to create a wrapper script to call smem after your program closes.<br />
<br />
You need to write a custom script that does the following:<br />
* kill all running processes associated with your user account<br />
* auto logoff terminals<br />
* for the last terminal closed including all idle xservers, unmount your user home<br />
* (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack<br />
<br />
=== Sharing presentations over HDMI ===<br />
<br />
If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.<br />
<br />
To install libxinerama and xrandr do:<br />
<br />
sudo apk add libxinerama xrandr<br />
<br />
== Important notes ==<br />
<br />
If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.<br />
<br />
I don't know if suspend-to-ram or hibernate sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor] This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://old.iseclab.org/papers/acsac2012dma.pdf] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.<br />
<br />
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]<br />
<br />
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.<br />
<br />
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.<br />
<br />
[[Category:Installation]]</div>Orson Teodoro