Arnavion

They're talking about Windows Bitlocker. It used to be able to use hardware encryption if the drive supported it, then there were sufficient vulnerabilities in implementations that it now always does software encryption.

I can't say anything about dual-booting Windows. I have heard that Windows Updates will frequently overwrite your custom EFI vars setup and reinstate the Windows bootloader etc.

Other than that, FDE and Secure Boot are unrelated.

The board's UEFI will boot the EFI binary that is either your kernel + initramfs (UKI binary), or a bootloader of your choice that then boots your kernel + initramfs. Depending on your distro, you may have a bootloader like grub or systemd-boot that is already signed by the MS third-party CA and your board may already allow the third-party CA, in which case you don't need to generate and sign with your own keys. Otherwise generate your own keys, set up Secure Boot with them, and then figure out how to sign your UKI binary / bootloader binary with those keys.

This initramfs will then be responsible for locating and mounting your root etc partitions. For a systemd distro using the UAPI Discoverable Partitions spec (use a specific type ID for the root partition), systemd has a builtin cryptsetup target that will prompt you on tty to enter the LUKS password for that partition. Otherwise investigate your distro's initramfs options for doing that.

>* Dual-boot where I choose in BIOS/UEFI to go to either the existing Win10 drive or new Linux drive.

grub and systemd-boot both show menus to select one of the available EFI binaries to chain to. Otherwise your UEFI might give you a similar menu.

>* I want to be able to take my drive out of a dead computer and access it elsewhere if something goes wrong, as opposed to needing to reformat and reload from backups.

Any other PC can mount and decrypt the drive with cryptsetup just like your original PC could, as long as you specify the same password.

>* If I install a distro with secure-boot off, can I turn it on later for benefits, or vice-versa?

Yes. You will launch board's UEFI, set the SB status to "Setup mode", boot your OS, then generate and enroll new keys which will set the SB to "User mode" and start enforcing signatures on next boot. And if it breaks you can set it back to "Setup mode" in board's UEFI, boot the OS and troubleshoot / re-enroll keys. The OS wouldn't care that you had previously enabled SB but are now booting with SB disabled.

Note that Secure Boot != Measured Boot. With a standard Measured Boot setup the disk encryption key is protected by secure element on the board (eg TPM) measuring the boot chain, so your disk will automatically decrypt when the boot chain matches the previous measurement and automatically fail to decrypt when it doesn't match. Your concerns about failing to decrypt the disk apply to this setup, not to SB. But also LUKS-encrypted partitions can have multiple keys to unlock them, so you can have both a Measured Boot-guarded encryption key and an emergency fallback password to unlock the disk manually.

You're right, I missed the article specifically mentions Meltdown in that sentence, not Spectre.

The fetch stage of the pipeline will have needed to predict the branch N cycles before the execute stage of the pipeline actually gets around to evaluating it, in order to continue fetching the post-branch instructions. Without branch prediction the fetch stage would need to stall until that happens, which decreases throughput. The point of branch prediction and the subsequent speculative execution is to optimistically avoid that stall.

Speculative execution does not require out-of-order execution. When you predict a branch, you're speculatively executing the predicted branch. Whether you're doing it in the same order as instruction order or out of order is independent of that.

Ah yes, in that case the relevant limit would be one on total handles, which doesn't seem to exist.

The answers to negative questions are the other way around in Japanese compared to English.

"Are you not a student?"

In English, the non-student speaker would respond with "No", short for "No, I am not."

In Japanese, the non-student speaker would respond with "Yes", short for "Yes that's correct."

A literal translation would make this mistake.

>A character may say "I've missed you so much. It's been so long." The subtitles will read "Hey. Long time. " (both quotes would be Japanese)

This is standard in closed captions and is not specific to Japan. So perhaps the service you're talking about only has closed captions and is incorrectly marking them as subtitles.

CR rips (like SubsPlease, mentioned in the article) have jp audio and softsubs for en+signs, so I assume you can turn them off on CR's website too.