> This probably depends on a lot of non-public info: how does the PSP validate CPU state?

https://github.com/amd/AMD-ASPFW/blob/3ca6650dd35d878b3fcbe5...

That seems to be reading a memory mapped register per core. I wonder what backs that register.

It's just written by the CPU during a ucode update

> But raw write access to the flash depends on you being in SMM

Look at tests/stop.sh and check the different segments (ls:, ms:, etc you can also address them like 0:[..], 1, 2, 3,... 15:[...]). One of those is probably flash. If you know how that looks like try to dump it first with a load and then check which segment and which address it is at and then write back to it.

You can make a new instruction (or repurpose an existing one) that accesses physical memory bypassing the page walk, which would be faster. You can also make instructions that bypasses some checks (like privilege checks) and squeeze some tiny performance. Note this would introduce security issues though, so you could only use it on trusted software.

We were not able to demonstrate that Zen5 is affected. If we end up doing so, we may release a new advisory or something.

151515 is such an elitist number.. 3 * 13 * 37 * 3 * 5 * 7

[citation needed]

* ChromeOS, COS and Android are opensource, and they are all up to date. Mind elaborating?

With respect to Android, I was under the impression that (in part because key members of the Linux community are allergic to the notion of a stable device driver ABI) the specific release of linux used on a particular model of phone was typically frozen at some point before the time the phone shipped, and subsequently only patched as needed.

The mere fact that the source is available doesn't mean that someone will take the (potentially unbounded) time to port it to a future release and test it sufficiently.

> Sometimes I wish there was a Linux kernel security advisory process, but this would need funding or a dedicated volunteer.

This is already happening https://osv.dev/list?q=Kernel&affected_only=true&page=1&ecos...

As far as I know, this doesn’t get information from upstream maintainers. For this to work well, I think we would want actual advisories generated around commit time, embargoed early notification, and a process for publication.

for what is worth, the link gregkh pointed you to explains the answer for your first 2 points.

Your last point is wrong. Simple example, which of the following thousand bugs are exploitable? https://syzkaller.appspot.com/upstream

If you can exploit them, you can earn 20,000 to 90,000 USD on https://google.github.io/kctf/vrp

I've read the post before, I've seen the talk, and frankly it's been addressed a number of times. It's the same silly nonsense that they've been touting for decades ie: "a bug is a bug".

They don’t need to label it security even, just a “upgrade now, upgrade soon, upgrade whenever”.

But they clearly don’t want nor care about making that call (and even more clearly basically expect everyone to run the latest kernel at all times (and if you run into a bug there no doubt you’ll be told to not run the latest kernels).

about duplicates - google has this thing called grants https://bughunters.google.com/about/rules/5479188746993664 that pay people for doing security research, even if they don't find any bugs. we agree that doing security research is valuable even if no bugs are fixed.

about having access to private bugs, we don't want to share vulnerabilities with others without the researcher's permission, but the original researcher can make bugs public on the new website, you can see some of them here https://bughunters.google.com/report/reports

It can be tiring at times.