__NOINDEX__ {{header}} = Full Disk Encryption encrypted /boot GRUB Keyboard Layout Issue = '''{{IconSet|h2|4}} Notice for users of full disk encryption.''' If you would like to use [[Full_Disk_Encryption|full disk encryption (FDE)]], it can be done in the Partition tab. Choose "Encrypt system".
If you choose full disk encryption and your keyboard is NOT ''en_US QWERTY'', please press on 'Learn More' on the right side.
'''Encryption Versus Keyboard Layout''' The Calamares installer will encrypt /boot but with English US QWERTY keyboard. This can be confusing. The user might type the password in their local keyboard layout while GRUB at boot time will be interpreting the password using English US QWERTY keyboard layout. * en_US QWERTY keyboards: This is a non-issue for users using US keyboards. * other keyboards: This issue exists. Which workarounds are available to users? Choose one. * '''A)''' Use a separate English US QWERTY keyboard for password entry; * '''B)''' Avoid characters which are different on your local vs the English US QWERTY keyboard layout; * '''C)''' Use a different installation method. Using [[Debian|Distribution morphing]] it will be possible to avoid [[Full_Disk_Encryption#encrypted_boot|encrypted /boot]] by using Debian's old installer ([https://www.debian.org/releases/stable/i386/ch01s04.en.html "d-i"] [https://wiki.debian.org/DebianInstaller/GUI Debian's installer GUI (GTK based)]); * '''D)''' Not using full disk encryption. Not recommended. Less realistic workarounds, for developers only and tickets, see footnote. Less realistic workarounds: * '''F)''' Workaround the bug by patching {{project_name_short}} Calamares installer to use unencrypted /boot; * '''G)''' Fix the GRUB bug. Tickets: * installer, Calamares bug report [https://github.com/calamares/calamares/issues/1203 Encryption does not work well with non-QWERTY keyboards] * Debian feature request: [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686817 grub-pc: Add option to change keyboard layout] * bootloader, GNU grub feature request: [https://savannah.gnu.org/bugs/index.php?65113 Add All Keyboard Layouts and Selector to Early GRUB Core Image (grubx64.efi)] = VirtualBox read-only mode = {{Box|text= '''1.''' Warning. {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = Issue: VirtualBox might no longer support VBoxInternal/Devices/lsilogicsas/0/LUN#0/AttachedDriver/Config/ReadOnly. Settings set through VBoxManage setextradata are not officially supported and might be gone at some time such as now. }} '''2.''' Set the VM disks to read-only. Follow these steps: * Power off the virtual machine (VM). * Set the disk to read-only. ** The name of the VM in the following example below is {{project_name_workstation_short}}-Xfce. It could be replaced with the name of any other VM such as {{project_name_gateway_short}}-Xfce. ** On the host command line, run. {{CodeSelect|code= VBoxManage setextradata {{project_name_workstation_short}}-Xfce "VBoxInternal/Devices/lsilogicsas/0/LUN#0/AttachedDriver/Config/ReadOnly" 1 }} '''3.''' Remove VirtualBox virtual DVD drive. This is only required if the VM has a virtual DVD drive. It is not required in {{project_name_short}} version 15.0.1.2.7 and above since it no longer comes with a virtual DVD drive by default. See footnote for a {{project_name_short}} build version lower than 15.0.1.2.7. {{VirtualBox_DVD_Remove}} https://forums.whonix.org/t/no-longer-add-virtual-dvd-drive-to-vm-by-default/9337 '''4.''' Launch the live system. Following reboot, a second boot entry called "VM Live Mode-mode" will be visible. Select it and then press Enter to boot the live system and use it as normal. '''5.''' ''Optional:'' Revert the read-only change. To boot into normal mode again, run this command on the host to revert the change. {{CodeSelect|code= VBoxManage setextradata {{project_name_workstation_short}}-Xfce "VBoxInternal/Devices/lsilogicsas/0/LUN#0/AttachedDriver/Config/ReadOnly" }} The normal boot option can now be selected in the GRUB menu. '''6.''' ''Optional:'' Re-add the virtual DVD. Only when you need this; see footnotes. {{VirtualBox_DVD_Add}} '''7.''' Done. The process has been completed. }} Troubleshooting: If the system does not boot, check the [[VirtualBox/Recommended_Version|Recommended VirtualBox Version]] for {{project_name_short}} VirtualBox is in use. = VirtualBox Generic Bug Reproduction using virtualbox-guest-additions-iso = This entry is based on [[Reporting_Bugs#Bug_Report_Recommendations|Bug Report Recommendations]], specifically [[Reporting_Bugs#Generic_Bug_Reproduction|Generic Bug Reproduction]]. The content is similar to the [[#Try a non-whonix VM|Try a non-{{project_name_long}} VM]] chapter above. A manual reproduction of the [[Dev/VirtualBox#VirtualBox_Integration|{{project_name_short}} VirtualBox Integration]]. # Use the [https://www.whonix.org/wiki/Host_Operating_System_Selection#Recommended_Linux_Distribution recommended] ([http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Host_Operating_System_Selection .onion]) Linux distribution -- [https://www.debian.org/ Debian] {{Stable project version based on Debian codename}} -- as the host operating system. ([[Debian Tips]]) # Install the [[VirtualBox/Recommended_Version|recommended version of the VirtualBox host software]]. # Installation of non-freedom software is not required, but the Debian "nonfree" (free in price but non-freedom) repository must be temporarily enabled; the reason is documented below. # [https://packages.debian.org/virtualbox-guest-additions-iso virtualbox-guest-additions-iso] (Freedom Software) from the Debian repository on the the Debian host operating system. Due to a [[Dev/VirtualBox#VirtualBox_Guest_Additions_ISO_Freedom_vs_Non-Freedom|Debian packaging bug]] the package is only available from Debian nonfree repository, but the package is not non-freedom. That package provides file /usr/share/virtualbox/VBoxGuestAdditions.iso. # Install Debian {{Stable project version based on Debian codename}} inside a VirtualBox VM. # Mount the VirtualBox Guest Additions CD iso file /usr/share/virtualbox/VBoxGuestAdditions.iso inside the Debian VM. # Install VirtualBox Guest Additions from the virtual CD-ROM drive inside the Debian VM. Change to the directory where the CD-ROM drive is mounted and run the following command as root: sh ./VBoxLinuxAdditions.run # Attempt to reproduce the original issue. = NTP = == Disabling NTP == If ISP tampering with NTP is ever confirmed, users are advised to [[Time_Attacks#GNU.2FLinux_Host|disable NTP]] and manually update the host clock out-of-band. For example, a watch or [https://en.wikipedia.org/wiki/Atomic_clock atomic clock] can be used for this purpose. If the tampering is targeted and not a widescale attack, then the user already has much bigger problems to worry about than NTP; see [[Warning#Confirmation_Attacks|Confirmation Attacks]]. If following the advice above -- disabling NTP on the host and adjusting the clock out-of-band -- be aware that clearnet traffic might be easier to fingerprint. See the [[Fingerprint]] page to discover what fingerprinting means in this case. The reason is that it introduces a device issuing clearnet traffic (such as OS updates), but without the use of NTP. It is unknown how many people have NTP which is deactivated, broken, uninstalled, or never in fact installed in the first place. Also unknown is how many people are using alternative time synchronization methods such as authenticated NTP, [https://tails.boum.org/contribute/design/Time_syncing/ tails_htp], [https://github.com/ioerror/tlsdate/ tlsdate], [[sdwdate]] or similar. However, search engine research suggests that very few people fall into both these categories. == NTP Issues == The host system clock synchronization mechanism still uses unauthenticated NTP from a single source. This is not optimal, but there is no real solution to this problem. See Design: [[Dev/TimeSync]]. A potential attack vector is created by this NTP behavior; the ISP and/or time server could either inadvertently or maliciously introduce a significant clock skew, or the host clock could simply malfunction. If the host clock value is grossly inaccurate -- more than one hour in the past or more than 3 hours in future -- Tor cannot connect to the Tor network. In this case, Tor cannot verify the Tor consensus. This is easily solved by manually fixing the clock on the host, then powering the {{project_name_gateway_long}} off and on again. Another side effect of a significantly inaccurate host clock concerns operating system (OS) updates and cryptographic verification on the host. Until the host clock is manually fixed, it may no longer be possible to download updates or verify SSL certificates correctly with the host browser. Users should always check whether a host clock defect relates to an empty battery before assuming the ISP is tampering with NTP. = ??? = == KVM ==
For KVM, click on Expand on the right.
[[KVM#XML_Modification_.28OPTIONAL.29|Edit the VM xml before import]] or [[KVM#Editing_an_imported_Machine.27s_XML_Configuration|edit the VM xml after import]] and change the following setting. {{CodeSelect|code= }} To. {{CodeSelect|code= }} The adjustment attribute takes any arbitrary value for seconds. The user must pick a random value that is unknown to others, ranging between 0 and 900 (a 15 minute range).
== Qubes == TODO Unfortunately, it is not yet possible to set a random clock offset for {{q_project_name_long}} VM to prevent clock correlation attacks since it is [https://phabricator.whonix.org/T440 unsupported by Xen]. A related issue is [https://phabricator.whonix.org/T389 denying {{q_project_name_long}} access to "clocksource=xen"], which may not be possible without Linux kernel and/or Xen patches. For a detailed discussion of these issues, see [https://groups.google.com/forum/#!topic/qubes-devel/aN3IOv6JmKw here]. == VirtualBox ==
For [[VirtualBox]], click on Expand on the right.
VirtualBox has a feature to spoof the initial virtual hardware clock offset by setting the clock X milliseconds in the future or past. The syntax is outlined below. {{CodeSelect|code= VBoxManage modifyvm --biossystemtimeoffset - VBoxManage modifyvm --biossystemtimeoffset + }} It is recommended to add a random delay within the following range. {{CodeSelect|code= VBoxManage modifyvm --biossystemtimeoffset -60000 VBoxManage modifyvm --biossystemtimeoffset +60000 }} A spoofing example is below. Users should select their own unique and random values for both the past (-) and future (+) within the specified range. Different values should be used for each distinct VM (on the host). {{CodeSelect|code= VBoxManage modifyvm "{{project_name_gateway_short}}" --biossystemtimeoffset -35017 VBoxManage modifyvm "{{project_name_gateway_short}}" --biossystemtimeoffset +27931 VBoxManage modifyvm "{{project_name_workstation_long}}" --biossystemtimeoffset -35017 VBoxManage modifyvm "{{project_name_workstation_short}}" --biossystemtimeoffset +27931 }} Apart from this small biossystemtimeoffset, a clock skew always degrades privacy. biossystemtimeoffset is used to unlink the virtualizer's initial clock synchronization of the VM from the host clock. After powering on a VM, it initially synchronizes the VM clock with the host clock until {{project_name_short}} Timesync adjusts it.