Episode 410

Epyc Encryption

00:00:00
/
00:50:07

August 23rd, 2019

50 mins 7 secs

Your Hosts
Tags

About this Episode

It's CPU release season and we get excited about AMD's new line of server chips. Plus our take on AMD's approach to memory encryption, and our struggle to make sense of Intel's Comet Lake line.

Also, a few Windows worms you should know about, the end of the road for EV certs, and an embarrassing new Bluetooth attack.

Episode Links

  • A detailed look at AMD’s new Epyc “Rome” 7nm server CPUs | Ars Technica — The short version of the story is, Epyc "Rome" is to the server what Ryzen 3000 was to the desktop—bringing significantly improved IPC, more cores, and better thermal efficiency than either its current-generation Intel equivalents or its first-generation Epyc predecessors.
  • AMD Rome Second Generation EPYC Review: 2x 64-core Benchmarked — Ever since the Opteron days, AMD's market share has been rounded to zero percent, and with its first generation of EPYC processors using its new Zen microarchitecture, that number skipped up a small handful of points, but everyone has been waiting with bated breath for the second swing at the ball. AMD's Rome platform solves the concerns that first gen Naples had, plus this CPU family is designed to do many things: a new CPU microarchitecture on 7nm, offer up to 64 cores, offer 128 lanes of PCIe 4.0, offer 8 memory channels, and offer a unified memory architecture based on chiplets.
  • AMD EPYC Rome Still Conquering Cascadelake Even Without Mitigations - Phoronix — Out of curiosity, I've run some unmitigated benchmarks for the various relevant CPU speculative execution vulnerabilities on both the Intel Xeon Platinum 8280 Cascadelake and AMD EPYC 7742 Rome processors for seeing how the performance differs.
  • Intel’s line of notebook CPUs gets more confusing with 14nm Comet Lake | Ars Technica — Going by Intel's numbers, Comet Lake looks like a competent upgrade to its predecessor Whiskey Lake. The interesting question—and one largely left unanswered by Intel—is why the company has decided to launch a new line of 14nm notebook CPUs less than a month after launching Ice Lake, its first 10nm notebook CPUs.
  • A look at the Windows 10 exploit Google Zero disclosed this week | Ars Technica — On Tuesday, Tavis Ormandy of Google's Project Zero released an exploit kit called ctftool, which uses and abuses Microsoft's Text Services Framework in ways that can effectively get anyone root—er, system that is—on any unpatched Windows 10 system they're able to log in to
  • Patch new wormable vulnerabilities in Remote Desktop Services (CVE-2019-1181/1182) – Microsoft Security Response Center — Today Microsoft released a set of fixes for Remote Desktop Services that include two critical Remote Code Execution (RCE) vulnerabilities, CVE-2019-1181 and CVE-2019-1182. Like the previously-fixed ‘BlueKeep’ vulnerability (CVE-2019-0708), these two vulnerabilities are also ‘wormable’, meaning that any future malware that exploits these could propagate from vulnerable computer to vulnerable computer without user interaction.
  • KNOB Attack — TL;DR: The specification of Bluetooth includes an encryption key negotiation protocol that allows to negotiate encryption keys with 1 Byte of entropy without protecting the integrity of the negotiation process. A remote attacker can manipulate the entropy negotiation to let any standard compliant Bluetooth device negotiate encryption keys with 1 byte of entropy and then brute force the low entropy keys in real time.
  • Troy Hunt: Extended Validation Certificates are (Really, Really) Dead — With both browsers auto-updating for most people, we're about 10 weeks out from no more EV and the vast majority of web users no longer seeing something they didn't even know was there to begin with! Oh sure, you can still drill down into the certificate and see the entity name, but who's really going to do that? You and I, perhaps, but we're not exactly in the meat of the browser demographics.
  • Google wants to reduce lifespan for HTTPS certificates to one year | ZDNet — Scott Helme argues that the security benefits of shorter SSL certificate lifespans have nothing to do with phishing or malware sites, but instead with the SSL certificate revocation process. Helme claims that this process is broken and that bad SSL certificates continue to live on for years after being mississued and revoked.