Except that many component manufacturers release their efi capsules signed with Microsoft PKI. So no, you can't fully remove them if you want to verify updates.
If you're interested in the topic there's great YouTube channel that demonstrates such attacks IRL together with full tutorials. Below are 2 satellite related videos:
Not the best name for the article. My first guess was version changes, or software being added/removed from repo. Turns out this is about source code modification.
A problem I encountered while writing custom stdlib, is that certain language features expect stdlib to be there.
For example, <=> operator assumes, that std::partial_ordering exists. Kinda lame. In the newer C++ standards, more and more features are unusable without stdlib (or at least std namespace).
Both AMD and Google note, that Zen[1-4] are affected, but what changed about Zen5? According to the timeline, it released before Google notified AMD [1].
Is it using different keys, but same scheme (and could possibly be broken via side-channels as noted in the article)? Or perhaps AMD notices something and changed up the microcode? Some clarification on that part would be nice.
Honestly I don't get why people are hating this response so much.
Life is complex and vulnerabilities happen. They quickly contacted the reporter (instead of sending email to spam) and deployed a fix.
> we've fundamentally restructured our security practices to ensure this scenario can't recur
People in this thread seem furious about this one and I don't really know why. Other than needing to unpack some "enterprise" language, I view this as "we fixed some shit and got tests to notify us if it happens again".
To everyone saying "how can you be sure that it will NEVER happen", maybe because they removed all full-privileged admin tokens and are only using scoped tokens? This is a small misdirection, they aren't saying "vulnerabilities won't happen", but "exactly this one" won't.
So Dave, good job to your team for handling the issue decently. Quick patches and public disclosure are also more than welcome. One tip I'd learn from this is to use less "enterprise" language in security topics (or people will eat you in the comments).
If you want to manage VMs, then you're probably using terraform + provider. However, SDN (Software Defined Networking) is not yet supported [1], which makes any kind of deployment with network separation not feasible (using IAC only).
I'm not a rust expert by any means, but I believe there's a problem with lifetimes. There are many ways to implement double-linked lists (think C++ smart pointers), but when you try to squeeze performance and use references, then it's a fight against borrow checker, which ends with the need to use unsafe rust.
While authelia is quite cool "infra-as-code" tool, since you have your entire configuration in yaml form, for those not willing to spend a few evenings configuring SSO, there is authentik [1] which features management UI.
Offers similar feature set, also self-hostable, but most importantly - simple to set-up. I've spent 8h on authelia deployment, where 30 minutes in authentik would be sufficient. But both are good options, pick what you prefer.
When performing forensic analysis, metrics don't usually help that much. I'd rather sift 2PB of logs, knowing that information I'm looking for is in there, than sit at the usual "2 weeks of nginx access logs which roll over".
Obviously running everything with debug logging just burns through money, but having decent logs can help a lot other teams, not just the ones working on the project (developers, sysadmins, etc.)
stdlib changes as it wants from version to version. So do language features. Since zig is pre-1.0, zig foundation isn't scared of breaking changes.