HN user

dTP90pN

66 karma
Posts0
Comments31
View on HN
No posts found.

The real solution is obviously to use geolocation to find the closest country which officially uses the individual language(s).

This does not account for inattentional deafness, which is why there ought to be sense-redundant alerts, at least for alerts requiring immediate action.

If you're not running a Zen 2 CPU or APU, you don't have to worry about this.

If you're running the latest kernel, which automatically sets the chicken bit, you don't have to worry about this.

If you're running fixed microcode, which is only available for Rome, Castle Peak and Mendocino, you don't have to worry about this. Good microcode revisions are:

    Rome / Castle Peak: 0x0830107a (published)
    Xbox Series X: unknown
    Renoir / Grey Hawk: 0x0860010b
    Lucienne: 0x08608105
    Matisse: 0x08701032
    Van Gogh (Steam Deck): unknown
    Mendocino: 0x08a00008  (published) 


If you're running neither the latest kernel, nor fixed microcode, you should set the chicken bit yourself until you have updated those.
    wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))
Zenbleed 3 years ago

AMD have released an microcode update for affected processors.

I don't think that is correct. AMD has released a microcode update[0] for family 17h models 0x31 and 0xa0, which corresponds to Rome, Castle Peak and Mendocino as per WikiChip [1].

So far, there seems to be no microcode update for Renoir, Grey Hawk, Lucienne, Matisse and Van Gogh. Fortunately, the newly released kernels can and do simply set the chicken bit for those. [2]

[0] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

[1] https://en.wikichip.org/wiki/amd/cpuid#Family_23_.2817h.29

[2] https://github.com/torvalds/linux/commit/522b1d69219d8f08317...

Have you looked at the crash reports via `about:crashes`? This should show you if there's any open bug report associated with the crash(es) you encounter.

Regarding libdbus-glib-1-2, you may want to open a bug. It looks like [1] it's mainly used by the ~12 year old UPowerClient, and more recently, for wake/sleep and timezone change notifications (nsAppShell).

[1] https://searchfox.org/mozilla-central/search?q=DBusG.*&path=...

Do you mean native JSDoc namepaths like

    /**
     * @type {module:look/here~MyType}
     */
or TypeScript "JSDoc" imports like
    /**
    * @type {typeof import("./look/here").MyType}
    */
or both?

Did that end up becoming a problem in all the other distros using aliased directories, for example Fedora which has 10 years of experience with this scheme? An quick look on Fedora 35 with

  $ grep -rP "(?!(?=(?'a'[\s\S]*))(?'b'\/usr(?=\k'a'\z)|(?<=(?=x^|(?&b))[\s\S])))\/bin\/(?!(sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat))" /usr/bin

doesn't really show any objectionable binaries being referred to via /bin (I count those I excluded in the negative lookahead as certainly non-objectionable).

(I used the variable-length negative lookbehind [1] because I wanted to reduce false positives, but just scrolling through the results ended up being easier)

[1] http://www.drregex.com/2019/02/variable-length-lookbehinds-a...

Alternatively, a simple

   grep --binary-files=text -rP '(?<!/usr)/bin/(?!sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat)' /usr/bin
to also include binary files does the job as well.

The newer 12-page version on the preprint server has a PDF creation date of 3/3/2021, 11:32:56 AM, created with pdfeTeX-1.30.4.

https://eprint.iacr.org/eprint-bin/getfile.pl?entry=2021/232...

The previous (reportedly wrongly uploaded) version is from 12/5/2019, 9:10:13 AM created with pdfeTeX-1.30.4.

https://eprint.iacr.org/eprint-bin/getfile.pl?entry=2021/232...

The university website version is from 3/5/2020, 12:00:19 PM created with pdfTeX-1.40.15.

These dates & times are MM/DD/YYYY & CET.

A co-editor of the Cryptology ePrint Archive confirmed the submission on twitter:

https://twitter.com/Leptan/status/1367103240228261894