• 0 Posts
  • 17 Comments
Joined 1 个月前
cake
Cake day: 2026年4月7日

help-circle
  • From the grapheneos faq section on device support, which details the kinds of hardware and firmware security features required and present on pixels (but may be missing on other devices):

    Hardware, firmware and software specific to devices like drivers play a huge role in the overall security of a device. The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware.
    Non-exhaustive list of requirements for future devices, which are standards met or exceeded by current Pixel devices:

    • Support for using alternate operating systems including full hardware security functionality
    • Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)
    • At least 5 years of updates from launch for device support code with phones (Pixels now have 7) and 7 years with tablets
    • Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they’re released)
    • Linux 6.1, 6.6 or 6.12 Generic Kernel Image (GKI) support
    • Hardware accelerated virtualization usable by GrapheneOS (ideally pKVM to match Pixels but another usable implementation may be acceptable)
    • Hardware memory tagging (ARM MTE or equivalent)
    • Hardware-based coarse grained Control Flow Integrity (CFI) for baseline coverage where type-based CFI isn’t used or can’t be deployed (BTI/PAC, CET IBT or equivalent)
    • PXN, SMEP or equivalent
    • PAN, SMAP or equivalent
    • Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode and decode, image processor and other components
    • Support for A/B updates of both the firmware and OS images with automatic rollback if the initial boot fails one or more times
    • Verified boot with rollback protection for firmware
    • Verified boot with rollback protection for the OS (Android Verified Boot)
    • Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)
    • StrongBox keystore provided by secure element
    • Hardware key attestation support for the StrongBox keystore
    • Attest key support for hardware key attestation to provide pinning support
    • Weaver disk encryption key derivation throttling provided by secure element
    • Insider attack resistance for updates to the secure element (Owner user authentication required before updates are accepted)
    • Inline disk encryption acceleration with wrapped key support
    • 64-bit-only device support code
    • Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers
    • Support for disabling USB data and also USB as a whole at a hardware level in the USB controller
    • Reset attack mitigation for firmware-based boot modes such as fastboot mode zeroing memory left over from the OS and delaying opening up attack surface such as USB functionality until that’s completed
    • Debugging features such as JTAG or serial debugging must be inaccessible while the device is locked






  • You have enough failures on each disk to make me suspect an issue with the usb-connected drive bay. I ran into similar issues with a cheap pci-e sata adapter, where little hiccups and latency in the communication layer would cause zfs to take disks offline randomly. Read, write, and checksum errors would slowly accumulate across all of the disks. Switched that machine to a proper enterprise hba, the issues vanished, and the disks are all healthy 3-4 years later.




  • I (mostly jokingly, but also a little bit really and sentimentally) believe that physical baremetal computers/servers have souls, and must therefore have hostnames that are names, because names are powerful and soulful and you should have respect for things that have souls. Which is why I kind of hate the “cattle, not pets” model in my own practice.

    Stick identifying categorizing prefixes on it, of course, and you can group clusters under the same name with a numeric suffix, but it’s gotta have a real name in there somewhere.





  • A friend of mine was once the organist at a cathedral with a grand pipe organ. He invited me to see it one day and hear him play, and for the finale he had me climb up into the forest of towering pedal pipes, crouching between the rows, dwarfed by their looming height, while he played Bach’s Toccata and Fugue in D Minor.

    The sound hit me like a wave, so vast and tremendous and perfect. I felt utterly annihilated - tiny and shaken apart into nothing, a speck swept away in a cascading ocean of music, like the whole world was exploding in cataclysm and fractal rebirth all around me. Dazzling and enormous.

    And when the fugue peaked, I think that’s the closest to nirvana I’ve ever been. Just blown clean off the face of the earth.




  • A partial solution to this evil-maid attack vector is Heads firmware (a replacement for the bios/uefi itself), which lets you sign the contents of your unencrypted boot partition using a gpg key on a hardware token, and verify the integrity of the firmware itself using a totp/hotp key stored in the tpm.

    All the benefits of secure boot, but you get to control the signing keys yourself instead of relying on a vendor. It’s great stuff.


  • Everything I run, I deploy and manage with ansible.

    When I’m building out the role/playbook for a new service, I make sure to build in any special upgrade tasks it might have and tag them. When it’s time to run infrastructure-wide updates, I can run my single upgrade playbook and pull in the upgrade tasks for everything everywhere - new packages, container images, git releases, and all the service restart steps to load them.

    It’s more work at the beginning to set the role/playbook up properly, but it makes maintaining everything so much nicer (which I think is vital to keep it all fun and manageable).