the main purpose of boot integrity is ensuring that a reboot deletes even malware that exploited the kernel and got full r/w disk access
Secure boot on ARM devices is more secure than non-Intel TXT x86, and the firmware is usually written more competently. It can be replaced by measured boot since most SoC vendors (like qcom) do not provide proper secure boot, and Intel TXT is not widely available on x86.
Stars, I'm sounding really silly here, I should stop trying to simplify it.
TL;DR, UEFI secure boot established a chain of trust from the firmware to the OS. Intel TXT establishes a chain of trust from the IME to the firmware. Measured boot establishes a chain of trust from the IME to the OS on x86, or from the bootrom to the OS on ARM. ARM secure boot also establishes a full chain of trust from the bootrom to the OS, but it tends to be unavailable on most devices.
Bwrap is a joke compared to Android sandboxing. Android relies on well-tested Unix UID/GID permissions and very restrictive SELinux on top (I'm unsure if they also 3employ seccomp), with binder providing an easy and obvious security boundary. FD.O is botched together using relatively untested code paths and relies on confusing design with unclear security boundaries
ity [unit X-69] - VIOLENT FUCK
npub194…58sk0
2025-12-23 01:26:10 UTC
in reply to nevent1q…w7sg
Author Public Key
npub194nd9rq72lgjkzdpk88ee2gzsx6j6w8zva2cm9jvsxrvv8c564asz58sk0Seen on
wss://relay.momostr.pinkPublished at
2025-12-23 01:26:10 UTCEvent JSON
{
"id": "dac003fee936a61fd6325ab69c05f0852916f797caa2c5125e89f61ca3e3327d",
"pubkey": "2d66d28c1e57d12b09a1b1cf9ca90281b52d38e267558d964c8186c61f14d57b",
"created_at": 1766453170,
"kind": 1,
"tags": [
[
"p",
"55c38daec0d45886a83afe6c19c37fe3d9ead721f02929360c290e29f0ebb00d"
],
[
"e",
"1ae36201b9ee48e7db13cd8ff9915669f965272a3a0447fe68143b4ec5259989",
"",
"reply",
"1ae40562756eaf1d96fe1ba4f85201c9a1f8005c3516aab9e0a84fbb3e6f7e84"
],
[
"proxy",
"https://estradiol.city/@ity/115766275001844028",
"web"
],
[
"e",
"bf92f99ce71076e0caecb5bd056a75bcf08db1a6042c96f6134d68731e430e13",
"",
"root",
"55c38daec0d45886a83afe6c19c37fe3d9ead721f02929360c290e29f0ebb00d"
],
[
"p",
"2d66d28c1e57d12b09a1b1cf9ca90281b52d38e267558d964c8186c61f14d57b"
],
[
"p",
"1ae40562756eaf1d96fe1ba4f85201c9a1f8005c3516aab9e0a84fbb3e6f7e84"
],
[
"proxy",
"https://estradiol.city/users/ity/statuses/115766275001844028",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://estradiol.city/users/ity/statuses/115766275001844028",
"pink.momostr"
],
[
"-"
]
],
"content": "the main purpose of boot integrity is ensuring that a reboot deletes even malware that exploited the kernel and got full r/w disk access\n\nSecure boot on ARM devices is more secure than non-Intel TXT x86, and the firmware is usually written more competently. It can be replaced by measured boot since most SoC vendors (like qcom) do not provide proper secure boot, and Intel TXT is not widely available on x86. \n\nStars, I'm sounding really silly here, I should stop trying to simplify it.\n\nTL;DR, UEFI secure boot established a chain of trust from the firmware to the OS. Intel TXT establishes a chain of trust from the IME to the firmware. Measured boot establishes a chain of trust from the IME to the OS on x86, or from the bootrom to the OS on ARM. ARM secure boot also establishes a full chain of trust from the bootrom to the OS, but it tends to be unavailable on most devices.\n\nBwrap is a joke compared to Android sandboxing. Android relies on well-tested Unix UID/GID permissions and very restrictive SELinux on top (I'm unsure if they also 3employ seccomp), with binder providing an easy and obvious security boundary. FD.O is botched together using relatively untested code paths and relies on confusing design with unclear security boundaries",
"sig": "c9c6deca4f28e57e260a6f900038050335fa9e18020c506a5ec6d5dbbfe5b0dbb5a9943024aab0160fa4d7942bf8c1fb50e9fe63bf54275b3f714154ab39f85b"
}