Sergey Bugaev on Nostr: So basically memory unsafety vulnerabilities, at scale, are a given, as long as a ...
So basically memory unsafety vulnerabilities, at scale, are a given, as long as a process runs non-trivial C code; they're always going to happen. It makes no sense to blame particular instances of vulnerabilities being accidentally introduced, that's just how things are. And it's on hardware designers, and us, systems designers, to introduce mitigations to try and protect against the vulnerabilities in ways other than just not writing them.
Or, we could RiiR 🙂
Published at
2024-03-22 15:16:52Event JSON
{
"id": "8e801d417f079ffd7f338e2bb57470c1f5f61ac90d375ab73631286937994af6",
"pubkey": "4e0479fa0ac06987c8679a425e23762d114da6d275f916ce428405e4a569e419",
"created_at": 1711120612,
"kind": 1,
"tags": [
[
"proxy",
"https://floss.social/users/bugaevc/statuses/112140000487616593",
"activitypub"
]
],
"content": "So basically memory unsafety vulnerabilities, at scale, are a given, as long as a process runs non-trivial C code; they're always going to happen. It makes no sense to blame particular instances of vulnerabilities being accidentally introduced, that's just how things are. And it's on hardware designers, and us, systems designers, to introduce mitigations to try and protect against the vulnerabilities in ways other than just not writing them.\n\nOr, we could RiiR 🙂",
"sig": "fe9334c539098d88e1c23dbe1133c6ca5e44c2ba954ecb3c8a0b76d8f2cc9735640a273cb0d689066716979e34031a3b62ada02d60b6e80de2cb5092fd7b2cee"
}