October 2019 - cypherpunks - lists.cpunks.org

How a months-old AMD microcode bug destroyed my weekend [UPDATED]
by coderman 02 Nov '19

02 Nov '19

[Stylized image of spiders creeping across screen covered with code.][Enlarge](https://cdn.arstechnica.net/wp-content/uploads/2019/10/bugs… / Ryzen 3000's RDRAND function—what should be a high-quality pseudo-random number generator—just returns 0xFFFFFFFFF every time, until its microcode is patched. This weekend, I was excited to deploy my first Ryzen 3000-powered workstation in my home office. Unfortunately, a microcode bug—originally discovered in July but still floating around in large numbers in the wild—wrecked my good time. I eventually got my Ryzen 3700X system working, and it's definitely fast. But unfortunately, it's still bugged, and there's no easy way to fix it. Not long after the product launch, AMD Ryzen 3000 customers started noticing problems with their shiny new CPUs. Windows users couldn't successfully launch Destiny 2 (due to a power-management bug, unrelated to the one sidelining my system), and Linux users in many cases couldn't even get their system to boot. Jason Evangelho [covered](https://www.forbes.com/sites/jasonevangelho/2019/07/12/amd-motherb… the initial discovery and report of the bug at Forbes back in July, and an AMD representative provided him with a statement by email: > AMD has identified the root cause and implemented a BIOS fix for an issue impacting the ability to run certain Linux distributions and Destiny 2 on Ryzen 3000 processors. We have distributed an updated BIOS to our motherboard partners, and we expect consumers to have access to the new BIOS over the coming days. This sounds happy and upbeat, but the reality isn't quite so simple. When there's a bug in the CPU microcode, you're at the mercy of your motherboard vendor to release a new system BIOS that will update it for you—you can't just go to some download link at AMD and apply a fix yourself. AMD responded to the bug in July. As far as I can tell, AMD did so only by direct email response; there's no press release about it—and the company's response made it sound like everything would be fixed in a week or two. I have the unfortunate duty of reporting to you, three months later, that it is not. What’s an RDRAND? The microcode bug in question is a faulty response to the RDRAND instruction. Modern x86_64 CPUs—beginning with Intel's Broadwell and AMD's Zen architectures—are supposed to have high-quality onboard random number generators (RNGs), which use thermal "noise" to very rapidly offer high-entropy pseudorandom numbers to anybody with kernel-level access who wants it. [RDRAND](https://en.wikipedia.org/wiki/RdRand) is, in turn, the instruction that provides these random numbers. All of this is supposed to be fairly failsafe. There's a CPUID function call that checks for the availability of RDRAND, and there's also a "carry bit" in the return value from a call to RDRAND that's supposed to let the calling application know if the CPU's RNG was unable to generate a sufficiently random number. Unfortunately, unpatched Ryzen 3000 says "yes" to the CPUID 01H call, sets the carry bit indicating it has successfully created the most artisanal, organic high-quality random number possible... and gives you a 0xFFFFFFFF for the "random" number, every single time. Obvious RDRAND bug impacts When the RDRAND bug in Ryzen 3000 first surfaced back in June, Linux users widely reported that their entire Ryzen 3000-powered systems wouldn't boot. The failure to boot was due to systemd's use of RDRAND—and it wasn't systemd's first clash with AMD and a buggy random-number generator, unfortunately. A much earlier bug in older CPUs caused some AMD systems to stop generating properly "random" numbers after resuming from suspend. The new bug caused Ryzen 3000 users to never get any proper random numbers at all. Both problems caused lockups in Linux operating systems using systemd, so in May systemd committed a [patch](https://github.com/systemd/systemd/commit/b62bc66018fa1ada09554e7ee4… that falls back to using alternate RNG sources if systemd receives the characteristic 0xFFFFFFFF back from the RNG. (This kinda sucks, because 0xFFFFFFFF is technically a perfectly valid random number—the implication here is that, after a sufficient length of time, systemd will decide any system has a buggy RNG when it eventually receives the "bad" number, even if it has never seen that number before.) Systemd's patch is ugly, but it certainly works well enough to allow systems to boot. Unfortunately, it doesn't fix the actual problem, which is that the CPU's random number generator is no more "random" than a two-headed penny. On my own system, I spent my entire weekend chasing phantom problems, first suspecting the system's brand-new RX 590 graphics card and (necessarily) updating distro and kernel versions before haring off from there. [My shiny new system kept barfing these nasty BUG: soft lockup<br /> —PU#n stuck for 22s errors, which would rapidly lock the whole system up. This call trace from /var/log/syslog didn't tell me the actual problem, but it was the first clue.](https://cdn.arstechnica.net/wp-content/uploads/2019/10/calltrace.png… / My shiny new system kept barfing these nasty BUG: soft lockup —PU#n stuck for 22s errors, which would rapidly lock the whole system up. This call trace from /var/log/syslog didn't tell me the actual problem, but it was the first clue. Jim Salter Eventually, after many false trails and much swearing, coffee, and less-respectable beverages, I actually read the call trace from my frequent CPU lockups—and "WireGuard" was right there, in every one of them. As it turns out, WireGuard relies on RDRAND (when available) to generate new session IDs. The session IDs need to be unique, and WireGuard wants them not to be simple consecutive integers, so it pulls a pseudorandom value from RDRAND, compares it against its existing session ID list to make sure there's no collision, then assigns it to the session. Read that last part again carefully—it makes sure there's no collision first. If an existing session has the same ID as the new number, WireGuard asks RDRAND for another "random" number, checks it for uniqueness, and so on. Since RDRAND on my system—and any non-microcode-updated Ryzen 3000 system—always returned 0xFFFFFFFF no matter what, that means infinite loop. Infinite loops in kernel code are bad; they introduce you to the value of the hardware reset button in a hurry. I want to be very clear here, this is not a WireGuard bug! WireGuard correctly checks to see if RDRAND is available, fetches a value if it is, and correctly checks to see if the carry bit is set. Then it indicates that, not only is there a value, it's a properly random one. Nevertheless, it's a problem that will lock up affected systems hard. A modern system needs high-quality pseudo-random numbers for lots of tasks, and the security implications of "random" meaning "always return0xFFFFFFFF" are difficult to predict. One obvious candidate is Address Space Layout Randomization (ASLR). Both [Windows](http://blog.ptsecurity.com/2012/12/windows-8-aslr-internals.html) and [Linux](https://lwn.net/Articles/569635/) use RDRAND as at least part of the randomness used to make sure code is never loaded in the same order twice, which mitigates against [stack-smashing](https://en.wikipedia.org/wiki/Stack_buffer_overflow) attacks. Fixing the problem—or at least recognizing it As AMD's representatives told reporters back in July, the real fix comes from applying BIOS updates to your motherboard and hoping that the BIOS update also includes the microcode patch for the CPU itself. When I checked my own BIOS using the dmidecode utility, I saw a date of August 12, 2019. But when I looked at Asus' download page for my motherboard, I saw downloads dated in September! Hurray! So I downloaded the BIOS update, saved it to a FAT32 thumb drive, rebooted my system, and went into setup. Unfortunately, after successfully applying the update and rebooting again, I realized my error—yes, Asus showed a later date for the BIOS, but the actual version was the same as the one I already had—3.2.0. My CPU still thought 0xFFFFFFFF was the randomest number ever, always, no matter what. At this point, I began to get paranoid—systemd had already quietly worked around the bug. But with most applications just quietly ignoring the problem, how would I know if it ever had been patched? What if two years later, I was still vulnerable to stack-smashing that I shouldn't have been, due to ASLR that wasn't actually randomizing? I discovered that I could use the linux utility hexdump against the kernel device /dev/hwrng to demonstrate that I had the problem. Unfortunately, the WireGuard project's Jason Donenfeld warned me that /dev/hwrng could, on some systems, derive its randomness from other sources—so while seeing a bunch of FF from it demonstrates that you have the problem, seeing valid pseudorandom data doesn't necessarily demonstrate that you don't. So he generously whipped up a couple of test utilities for the purpose that safely access RDRAND directly. If you're a Linux user, you can download [rdrand-test.zip](https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdr…, unzip it, and run it directly in the folder that you unzipped it in. ./amd-rdrandbug will tell you in plain English whether you have this specific bug, and ./test-rdrand will output 20 test RDRAND fetches. So you can confirm for yourself that you're not vulnerable to similar bugs either—if running ./test-rdrand produces the same set of values every time, it doesn't really matter whether they "look random," your RNG is broken! If you're a Windows user, you have a little more work ahead of you. First, [download](https://ubuntu.com/download/desktop) an Ubuntu desktop installer, then create an Ubuntu installer thumb drive. Then you can boot into the Ubuntu thumb drive's live environment (click "Try Ubuntu") and download and run the tests from there: you@ubuntu-live:~$ wget https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdrand-test.zip you@ubuntu-live:~$ unzip rdrand-test.zip you@ubuntu-live:~$ cd rdrand-test you@ubuntu-live:~$ ./amd-rdrand.bug [In a sufficiently broad dataset, 20 consecutive 0xFFFFFFFF returns might be considered a valid "random" grouping. This is not a sufficiently broad dataset.](https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdrand-fai… / In a sufficiently broad dataset, 20 consecutive 0xFFFFFFFF returns might be considered a valid "random" grouping. This is not a sufficiently broad dataset. Jim Salter Conclusions A broken random-number generator is a very serious bug, and it's troubling that more hasn't been said or done about this issue by AMD in the last three months. Ryzen 3000 is a great CPU platform in general, and I've been very impressed with the new system... except for spending an entire frustrated weekend troubleshooting it, being uneasy about the impact this will have on my overall system security, and having no idea when I can expect to be able to actually fix it. I reached out to AMD representatives earlier today, and they've responded with questions about my hardware but no solutions yet. I'll update this article with any fixes or recommendations as they arrive. Update: When I reached out to AMD for comment, a representative inquired about the make and model of my motherboard (Asrock Rack X470D4U) and the representative reached out in turn to Asrock. Asrock's team offered a custom BIOS available with the appropriate microcode fix; I respectfully declined to flash a one-off BIOS for me and me only, but the better news is that Asrock told AMD that the BIOS update should be publicly available in mid-November. (It is worth noting that some motherboards do already have BIOS updates available which do include the microcode fixes. Why the Asrock Rack X470D4U wasn't one of them is anybody's guess.) Readers in comments have suggested workarounds and mitigations in the meantime. The first was to pass nordrand as an argument to GRUB when booting. That doesn't fix the issue; it tells the kernel not to use the RDRAND instruction, but that doesn't have any impact on the advertised availability of the instruction in general. It's still exposed to the system, and any code that checks for the availability of RDRAND via CPUID is still going to see it there, and will still be able to use it directly. This is also the case with the similar random.trust_cpu Linux boot option. Neither of these workarounds actually disables RDRAND, so neither actually fixes the issue. Readers also suggested that if the amd64-microcode package were installed, it would fix the issue. This, too, is not the case; the amd64-microcode and intel-microcode packages are both installed by default on all Ubuntu 19.10 systems, including the one I'm experiencing the RDRAND failure on. I contacted AMD and asked representatives to check the status of that package and see if anything needs to (or can) be done about updating it. https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-…

5 6

[WAR] a turning point? Brzezinski, Mastermind of US Hegemony, Says Abandon Imperial Pipe Dreams
by Zenaan Harkness 02 Nov '19

02 Nov '19

This looks highly significant to me - public statement of defeat of US "world hegemony" regime, by Brzezinsky, very arguably "the US regime's architect". ** Even Brzezinski, Mastermind of US Hegemony, Says Abandon Imperial Pipe Dreams (http://russia-insider.us9.list-manage.com/track/click?u=fa2faf7034c3c3c413c…) ------------------------------------------------------------ by Mike Whitney on Wed, Aug 31, 2016 The original title of this article was: The Broken Chessboard: Brezinski Gives up on EmpireThe main architect of Washington’s plan to rule the world has abandoned the scheme and called for the forging of ties with Russia and China. Read more » (http://russia-insider.us9.list-manage.com/track/click?u=fa2faf7034c3c3c413c…)

13 95

[zen@freedbms.net: Re: [WAR] ...]
by Zenaan Harkness 02 Nov '19

02 Nov '19

----- Forwarded message from Zenaan Harkness <zen(a)freedbms.net> ----- From: Zenaan Harkness <zen(a)freedbms.net> To: cypherpunks(a)lists.cpunks.org Date: Thu, 1 Sep 2016 22:35:47 +1000 Subject: Re: [WAR] ... List-Id: The Cypherpunks Mailing List <cypherpunks.lists.cpunks.org> On Thu, Sep 01, 2016 at 02:47:08AM -0600, Mirimir wrote: > How about we implement a working AP system? As I said in a previous thread, I now believe that to be fundamentally flawed - that it will not achieve anything resembling justice, even in the long term. Fundamentally, the oligarchs and humans generally need a much higher level of education and discourse. "When all you have is a hammer ..." In the current climate of a majority of extremely dummed down "citizens", who are and feel disempowered, who cling to any iota of power that presents such as any public lynching, where intelligent "discourse" is simply not possible, restraint never exercised and certainly not possible to exercise collectively, AP would be at best a hammer to completely destroy society. I support anarchism, not chaos. ----- End forwarded message -----

6 12

I'm trying to understand site https://mailing-list-archive.cryptoanarchy.wiki/
by jim bell 02 Nov '19

02 Nov '19

In the last couple of days, I wanted to remind myself of the timing of the first appearance of my Assassination Politics essay on the Cypherpunks list. My recollection is that I published Part 1 on the Digitaliberty mailing list, maintained by Bill Frezza, on FIDOnet. At that time, I was unaware of the existence of the Cypherpunks email list. At some point, somebody saw my essay, and posted a reference (or a copy) to Cypherpunks, I believe. And at some point, I was invited to the Cypherpunks list. But over 24 years later, I don't recall the exact timing. I know, I believe, that Part 2 wasn't written until later in July, 1995. So to recall this, I just searched for 'cypherpunks archive'. I found the site listed in the title, figuring that it would contain the information I sought. https://mailing-list-archive.cryptoanarchy.wiki/ That looked promising. I looked at: mailing-list-archive.cryptoanarchy.wiki which, promisingly, showed the years 1992-1999. So far, so good, Since the information I sought should have appeared in 1995, I clicked on that year, Weirdly, the information for March and April and June was not present, Huh? This was, pretty much, the time frame I needed to search, Am I imagining things? Could somebody look for various strings, like "Jim Bell", or "Assassination Politics", or "AP", etc? Well, it's not like my existence was entirely deleted. https://mailing-list-archive.cryptoanarchy.wiki/authors/jim_bell_jimbell_at… But something very weird is going on, The information I sought, is not included, Is this a mere accident? What is the pattern, here? Jim Bell

6 23

Re: I'm trying to understand site https://mailing-list-archive.cryptoanarchy.wiki/
by Ryan Carboni 01 Nov '19

01 Nov '19

Assassinations politics come off as one of those blunt metaphors that are easily misinterpreted. Jim Bell doesn't seem clever enough to come up with it so I think he stole the idea from someone else.

4 3

Non-trivial to figure this out about the West
by Ryan Carboni 01 Nov '19

01 Nov '19

The West is run by horrendously incompetent morons, lead by bloodthirsty sociopaths who have no idea why they keep getting accused of horrendous crimes. After all, people who reach such positions tend to be very gullible and naive. Fortunately for them, everyone is well understanding and protective of them since they are such nice people. Anyway, if the West goes in any direction but the direction as by their guided hand, they suddenly develop a backbone and enforce their principles.

2 1

May world be spared hunger, plague and western principles. - was U. S. A.! A-me-ri-cah, f--- yeah! - How to rule the world, U.S. style
by Zenaan Harkness 31 Oct '19

31 Oct '19

----- Forwarded message from Zenaan Harkness <zen(a)freedbms.net> ----- From: Zenaan Harkness <zen(a)freedbms.net> To: CypherPunks <cypherpunks(a)cpunks.org> Date: Thu, 18 Jun 2015 19:41:09 +1000 Subject: U. S. A.! A-me-ri-cah, f--- yeah! - How to rule the world, U.S. style http://russia-insider.com/en/hey-obama-what-about-serbias-territoral-integr… Summary at bottom, summarizing shifting position of "west" over some time: "So let us recount the western position: - It claimed to uphold the sovereignty and territorial integrity of other countries and the inviolability of borders in Europe - However, this did not extend to the sovereignty and the territorial integrity of Federal Yugoslavia which could be trampled at will - Nonetheless, albeit the territorial integrity of Federal Yugoslavia itself wasn’t worth anything, the territorial integrity of its constituent republics seeking independence was holy - Albeit the territorial integrity of the Yugoslav constituent republics of Slovenia, Croatia and Bosnia and Herzegovina was holy, the territorial integrity of Serbia was not - Albeit Slovenes, Croats and Bosnian Muslims could leave Yugoslavia, Serbs could not leave Croatia and Bosnia - Albeit Serbs could not leave Croatia and Bosnia, Kosovo Albanians could secede from Serbia - Albeit Kosovo Albanians could secede from Serbia, Kosovo Serbs could not secede from Albanian-run Kosovo - Albeit Kosovo could unilaterally secede from Serbia under NATO military control, Crimea could not unilaterally secede from Ukraine under Russian military control May world be spared hunger, plague and western principles. " ----- End forwarded message -----

1 0

Old news: Why Mark Zuckerberg covers his laptop's camera and micophrone
by Georgi Guninski 31 Oct '19

31 Oct '19

=== Why Mark Zuckerberg covers his laptop's camera and micophrone Is taping your laptop a necessary security precaution? The chief executive officer of Facebook apparently thinks so. https://www.csmonitor.com/Technology/2016/0623/Why-Mark-Zuckerberg-covers-h… === Old joke: When we reach billions of insane people you won't insult as insane. (In Bulgarian: Когато станем милиарди луди, ще видиш то на кой ще викаш луд).

2 1

'Call it the Surge': Trump vows tougher militarized police; nationwide crackdown
by Razer 30 Oct '19

30 Oct '19

Shades of Richard Nixon! The "Silent Majority" 'told him' to do it. In this case the little hitler in Trump's head told him to. Maybe Trump doesn't remember how many cops got hurt and killed from the late 60s until the Vietnam War ended when Nixon tried it. After all he'd never heard of 'homelessness' until a few months ago. I'm SURE he never heard the chant: "We're bringing the war back home" used by armed protesters either... Tis a shame. > "President Donald Trump on Monday said the Justice Department is preparing to launch a sweeping crackdown on crime that he named "the surge," a term commonly associated with the George W. Bush administration's decision to send tens of thousands of additional troops into Iraq in 2007. "In coming weeks, Attorney General Barr will announce a new crackdown on violent crime—which I think is so important—targeting gangs and drug traffickers in high crime cities and dangerous rural areas," Trump said during the International Association of Chiefs of Police conference in Chicago. "Let's call it the surge." The president did not provide any details on the plan but said it is going to be "very dramatic." "And you're going to see tremendous results very quickly," Trump added. As if to emphasize his view of America's cities as war zones, Trump went on to tout his administration's success in putting military equipment into the hands of U.S. police officers and claimed "Afghanistan is a safe place" compared to Chicago. "To help keep you safe, I've made $600 million-worth of surplus military equipment available to local law enforcement," Trump told the audience of police chiefs. "If you remember, the previous administration didn't want to do that... They didn't want to make you look so tough. They didn't want to make you look like you're a threat." Watch Trump's remarks: [video] Trump's visit to Chicago, the first of his presidency, was met with massive protests led by Indivisible Chicago and other progressive advocacy groups. Striking Chicago public school teachers also cleared their Monday afternoon schedule to take part in demonstrations against the president. "We have heard that President Donald Trump might be in town," leaders of the Chicago Teachers Union wrote in an email to members late Sunday. "If any members were inclined to show up outside his fundraiser in red, that would qualify as productive, in our view.” Thousands of protesters gathered and marched outside the Trump International Hotel and Tower in downtown Chicago, where the president attended a big-money campaign fundraiser after the law enforcement conference: [Tweetshots] "We're angry," Marj Halperin of Indivisible Chicago told The Guardian. "He is taking pleasure in the misery of our city. He doesn't know us. He's coming to our city to raise money, largely from people who don't live in this city, without ever having addressed, supported, listened to the people who really need help." --30-- https://www.commondreams.org/news/2019/10/28/call-it-surge-vowing-nationwid… Rr Sent from my Androgyne dee-vice with K-9 Mail

3 2

hilarious 2007 tor security hole
by Punk - Stasi 2.0 30 Oct '19

30 Oct '19

Low-Resource Routing Attacks Against Tor https://www.freehaven.net/anonbib/cache/bauer:wpes2007.pdf you could add "high speed" compromised nodes, simply by lying about them being "high speed". also, notice this https://www.freehaven.net/anonbib/cache/hs-attack06.pdf blatant hole in hidden services design 'found' by scum-master syverson in 2006 - same scum-master who 'designed' tor haha. I'm guessing these scumbags get bonunses by 'paper' written, so they write papers about their shitty 'designs' and then write papers 'attacking' the same garbage they coded. Priceless.

2 1