If you want to play mental poker with an arbitrary number of friends/enemies, I built a prototype with a really basic UI that extends the SRA81 protocol to support more than two players and that also removes the need to reveal the hands at the end of the game. https://secret.cards/
Similar higher-than-rated-bandwidth can be achieved on the TRS-80 Model 100, which uses an array of 10 HD44102 controllers. With an FPGA it is possible to draw full motion video on the LCD: https://twitter.com/qrs/status/1092410264316653568
The WEH001602A is pin compatible to the HD44780, with OLED output instead of LCD. In 8-bit parallel mode with an FPGA you can exceed the recommended clock rate to drive quite a bit of data into the displays: https://twitter.com/qrs/status/1088240598971310081
A few years ago I built an adapter to allow classic Mac CRT's to be used with BeagleBone or Raspberry Pi systems ( https://trmm.net/Mac-SE_video). X11 has supported 1-bit mono displays since forever, so it mostly worked out of the box with well written programs.
Watching youtube videos in 1-bit is an amazing aesthetic. Unfortunately all of my videos of it were on vine, so this Muybridge-esque cat video seems to be the only one that I cross-posted to twitter: https://twitter.com/qrs/status/1045272076750401536
12-eights for "microns turnabouts Como migraines": 9a7e6f41875b444851cb19f018cea83e6565762d88888888888813ac47d39ce7
Although I'm also a fan of "Georgetown surfboarded rips nodding", which hashes to the very pleasant 01234567894a7924a0a568c01ae2f48f93921fc9b4437d7866db3be132411b08
If you want to more easily configure UEFI Secure Boot on your Linux system, while also registering your own signing keys to eliminate the Microsoft and OEM ones: https://safeboot.dev/
Brad Templeton wrote about it: "I believe this CD is now a piece of history, as the world's first major eBook project using current fiction. At the time it was the largest anthology of current fiction ever published in one volume, and it may retain that title even today. Prior ventures were small or featured either unpublished writers or public domain works. This anthology featured novels that in most cases had not yet come out in paperback."
In practice it is a bit of a pain during the initial setup and package installation -- I was probably rebooting to recovery mode once a day or more to install some command line tool that I had forgotten about. Once the machine is configured then it is a more rare occurrence, although your usage might vary.
Something that I'm not happy about is that the snaps all live on the writable /var since they want to do automatic updates all the time. This is problematic for a locked-down configuration and might recommend against a snap based distribution.
Separating out the bootable bits from the rest of the packages might help, as would running more things in sandboxes. Another option that we're exploring is some lvm magic to create a snapshot, upgrade the snapshot, sign it, and then on the next reboot use it as the real root. This is also useful for fleet management -- the new root filesystem, kernel, initrd, etc can arrive "behind the scenes" and on the next reboot is the one that is used. Since the PCRs can be predicated as well, the PCR policy can be signed and sent along with the upgrade to make it seamless.
If you want LUKS encryption with signed policies to prevent brittle PCRs, rollback prevention with monotonic counters, and user pin to prevent dictionary attacks, plus TPM sealed TOTP to attest to the state of the firmware: https://safeboot.dev/
The TPM is not a DRM enforcement mechanism if you set it up for your own use. It is a very useful tool for taking control of machine that you own - it provides a way to prove* to yourself that the system booting with the firmware that you've approved, in the configuration that you setup, and running the kernel and initrd that you've signed. https://safeboot.dev/attestation/#i-thought-remote-attestati...
Some forms of TPM tampering are explicitly addressed in the threat model:
> The PCR values in the TPM are not "secret", so an adversary with physical access could directly wire to the TPM and provide it with the correct measurements to extend the PCRs to match the signed values. The user PIN is still necessary to unseal the secret and the TPM dictionary attack protections both rate-limit and retry-limit the attacker.
Decaping chips to recover secrets is outside of the threat model, however.
A separate bootloader and key on USB does not protect against many physical attacks, nor ones that involve changing the firmware or nvram configuration through software attacks. Without some sort of sealed keys or attestation of the platform configuration, your external bootloader has no guarantees that the device itself has not been backdoored. mjg59's tpm-totp talk[1] discussed the difficulty of trusting the firmware that loaded the bootloader that loaded the kernel that is now asking for your password (although even with that it is necessary to add integrity protections on the encrypted disk, otherwise there are a variety of attacks against the systems).
Secure Boot is trustable, if you remove the vendor keys and reprogram the platform key with one under your own control. Likewise, the TPM is useful for protecting your secrets, not just enforcing DRM, if you take ownership of it and make use of the sealed key policies. See the safeboot.dev threat model[2] for how these protections are applied and how they detect or prevent many sorts of attacks.
This NSA report is a wonderfully thorough guide to configuring UEFI Secure Boot, although it is another example of how unusable security tools can be. This conplexity was my motivation for writing the safeboot[1] scripts, which wrap all of the signing key management, TPM key sealing, and attestation into a hopefully easier to use package.
That was exactly my motivation: there are tons of guides for setting up UEFI SecureBoot platform keys, yubikey tokens, TPM disk encryption, dmverity, etc, but all of them seemed to involve "type hundreds of commands with no mistakes and hope that your system still boots afterwards". It felt to me that each program represented a low-level library function that needed to be linked into a high-level tool to handle the common cases for most users.
Regarding /boot being in the clear -- the initramfs and kernel shouldn't contain any secrets, so having them unencrypted isn't a big drawback. Signed is much more important so that an adversary with write access to the disk can't swap out the kernel.
One advantage to using the TPM for unsealing the disk encryption key is that it helps protect against attacks that re-write the firmware. If an adversary can reflash the platform key (via either a local SPI flash programmer or some code execution that gives them write access to the NVRAM region of the flash), then you can't tell that the PK has been changed and that the kernel to which you are inputting the password is no longer trustworthy. Since the secret is sealed with (among other things) the hash of the UEFI SecureBoot configuration, the TPM will not unseal it if the PK, KEK or db are changed.
If you want to take it to another level, TPM TOTP can be used to validate that the password dialog is even valid before you type in the password. I think we can integrate that fairly easily into the initramfs for the next version of safeboot.
It's pretty typical boot time for most UEFI server platforms with network cards and RAID controllers. The Dell R630 takes about six minutes, the HP DL3x0 is about eight and the Lenovo x3550 takes over ten. Of the ones I've tested only the Intel s2600wf is under two minutes in a stock configuration, but with LinuxBoot it is less than twenty seconds to a Unix shell despite the PEI and DXE serial debugging messages: https://www.youtube.com/watch?v=0HISDFXZvSI
The threat model that LinuxBoot is addressing is different form SecureBoot and it can use the well known, normal Linux tools rather than the unconventional UEFI ones.
The Heads runtime can do things like use TPMTOTP to attest to the user that the firmware is unaltered and includes gnupg to verify the kernel and root filesystem signatures with the user's own key.
For cloud systems a LinuxBoot runtime can use the TPM or other trusted hardware to remotely attest to the client's own provisioning server that the configuration is unchanged, and since it is reproducibly built, that the firmware is what the user expects. This is significantly more trustworthy than the binary blobs and non-reproducible UEFI firmware on most servers.
The LinuxBoot kernel establishes a hardware root of trust with the TPM and measures the ROM before bringing up any IO devices, so when it connects to the network it is able to perform a remote attestation as to its state. This way the hosting provider or customer can decide to not provision a node that has somehow been modified by a prior tenant.
For a network booting scenario the LinuxBoot server can use GPG to validate the signature on the kernel that it receives over the network. Additionally, secrets can be sealed in the TPM and only unlocked if the received kernel matches the expected one (and if the local firmware is unmodified).