Live data from Hacker News

Viewing profile — sirdarckcat

sirdarckcat

HN member
Joined
Thu, Jan 10, 2013, 7:38 PM UTC
HN karma
149
Public activity
35 items

About sirdarckcat

No profile information was provided.

Recent public activity

  1. comment
    Comment #43287175

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

  2. comment
    Comment #43277583

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

  3. comment
    Comment #43277562

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

  4. comment
    Comment #43277510

    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 bypa…

  5. comment
    Comment #43277487

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

  6. comment
    Comment #40956060

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

  7. comment
    Comment #36351212

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

  8. story
  9. comment
    Comment #30592612

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

  10. comment
    Comment #30592419

    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 ex…

  11. story
  12. comment
    Comment #27974349

    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 fi…

  13. comment
    Comment #27974279

    It can be tiring at times.

  14. comment
    Comment #27685421

    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 weakne…

  15. comment
    Comment #27680986

    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 publi…

  16. comment
    Comment #27680941

    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 kn…

  17. comment
    Comment #27679739

    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…

  18. comment
    Comment #27677841

    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.

  19. comment
  20. story
  21. story
  22. comment
    Comment #14476006

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

  23. story
  24. story
  25. story