sirdarckcat

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

> 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...

> 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?

> 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...

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

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.

Insecurity is invisible. Users have no way to know the weaknesses in the software they use until it's too late. Disclosure is meant to make it possible for users to see what weaknesses they might have so they can make informed decisions.

Users still benefit to know about issues that can't be fixed (think about Rowhammer, Spectre and similar), so as these attacks become more practical (eg https://leaky.page or half double) they can adjust their choices accordingly (switching browsers, devices, etc) if the risk imposed by them is too high.

Of course (using an analogy for a second), some can say that it would be better for people to never find out that they are at increased risk of some incurable disease, because they can't do anything about it.

But for software, you can't make individual decisions like that. Even if one person doesn't want to know about vulnerabilities in the software they use, others could still actually benefit to know about them, and the benefit of the many trump over the preferences of the few.

That is, unless the argument is that it's actively damaging for all of the public (or the majority) to know about vulnerabilities in the software they use. If the point is to advocate for complete unlimited secrecy, and for researchers to sit on unfixed bugs forever, then that's quite an extreme view of software security and vulnerability disclosure (but that some companies unfortunately still follow).

Disclosure policies like these aim to strike a balance between secrecy and public awareness. They put the onus of disclosure on the finder because it's their finding (and they are the deciders on how it's shared), and finders are more independent than the vendor, but I could imagine a world in which disclosure happens by default, by the company, even for unfixed bugs.

Vulnerability deadlines are disclosure deadlines, not remediation deadlines. There's plenty of vulnerabilities that can't be fixed in that time, and I think it's fair for the public to know about them rather than keeping them secret forever.

Might be worth noting, 90 days are how long Google thinks it is reasonable to keep vulnerabilities secret without a fix.

The longer it is kept secret, the benefits of the public knowing about it outweigh the risks.

Not all vulnerabilities can be fixed in 90 days, but they can be disclosed.

Are you suggesting Google to make all unfixed vulnerabilities public after 90 days? Would that be even if the finder does not want them to become public? Or just as an opt-out type of thing.

http://g.co/appsecurity has more details but TL;DR is that Google is supportive of people disclosing unfixed bugs after 90 days, which is what happened here.

We added this section for the write-ups. We want to be able to republish write-ups and their code if we want.

The core library is in use in many Google products and runs across all browsers.

All security reports receive a "I filled a bug" after a bug is filled.

https://www.google.com/search?q=%22Nice%20catch!%20I%27ve%20...

Not a brush-off.

Hi!

Bounties are always awarded after the bug is disclosed[1].

We constantly[2] upgrade the bounties whenever we feel like we should be paying more, and we will continue to do so. We also increase the rewards from the amounts in the price list if we think they result in a higher impact than what the reporter originally suspected.

We aren't actually trying to out-pay the black market. Overall, our goal is to reward the security community for their time and help for their security research, since we both have the same goal in common of keeping all of us safe (either Google services, or open source/popular software[3]).

And if you are interested, you can follow news on Google's VRP here: - https://plus.google.com/communities/103663928590757646624

[1] http://www.google.com/about/appsecurity/reward-program/ [2] - http://googleonlinesecurity.blogspot.com/2010/11/quick-updat... - http://googleonlinesecurity.blogspot.com/2010/11/rewarding-w... - http://googleonlinesecurity.blogspot.com/2012/02/celebrating... - http://googleonlinesecurity.blogspot.com/2012/04/spurring-mo... - http://googleonlinesecurity.blogspot.com/2013/08/security-re... - http://googleonlinesecurity.blogspot.com/2013/06/increased-r... - http://googleonlinesecurity.blogspot.com/2014/02/security-re... [3] - http://googleonlinesecurity.blogspot.com/2007/10/auditing-op... - http://googleonlinesecurity.blogspot.com/2011/08/fuzzing-at-... - http://googleonlinesecurity.blogspot.com/2013/10/going-beyon... - http://googleonlinesecurity.blogspot.com/2013/11/even-more-p... - http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-... - http://www.google.com/about/appsecurity/research/