On Fri, Dec 01, 2017 at 01:07:59PM -0500, G. Branden Robinson wrote: > Hi Adam, > > I think you're probably already away of the factual portions of my > claims below, but I'm making them for the benefit of the broader > audience. > > At 2017-12-01T18:11:34+0100, Adam Borowski wrote: > > > > No, those derivatives are damage. While their hearts are in the right > > > > place, they cause data loss and security holes by at least making > > > > people on > > > > Intel and AMD machines use known-buggy microcode. > [...] > > While their _intent_ is good, they are telling others to run software with > > known severe bugs. > > It's wise to assume that all software that hasn't been formally _and_ > independently verified has severe bugs. And just because a bug is not > known to _you_ doesn't mean it isn't known to government snoops, > corporate revenue-maximizers, and criminals.
Earlier in this thread I wrote: --- Yeah, opaque encrypted microcode can be used to sneak in new backdoors, but that doesn't make past bugs (and "oh, those foul hackers found one of our backdoors, it was a honest bug, really!") any better. At the very least, you get new TLA-only backdoors while those fixed are usable by both TLAs and any random punk. Likewise, closed firmware for your wifi card is evil, but still strictly better than the same code burned into ROM: you get some bug fixes, and can go back to a past version. Sweeping non-free code under the carpet doesn't help in any way -- if you have to use it, it's better kept where you can see it. --- It's the difference between suspected (but indeed likely) brand new holes that are known to one corporation and a few spook agencies, vs old holes which have been disseminated to a wide array of bad guys. Plus, a long list of non-intentional data loss bugs. > > Microcode itself has data loss and local exploits (such > > as an unprivileged user of an unprivileged VM taking over the host machine), > > then often comes in one bunch with IME updates that close remote holes. > > And how do we know they aren't opening new ones due to the same factors > (bad design or bad intent) that led to the originals? > > > And once remote holes come into play, it's no longer a matter of just what's > > running on your own computer. > > We can be confident that all modern Intel- and AMD-based systems are > pre-compromised and running effectively hostile code fresh from the > factory. With this, I agree. It looks like some alternatives have appeared recently, like Talos 2 that's marketed as open (if you trust IBM), and fully free drivers (including the equivalent of ME/PSP) for Pinebook have finally been posted (currently in a form outside my u-boot/ATF/SPL skills, vagrantc is trying to figure it out). But then, Talos is a wee bit pricey for a client machine, while Pinebook's performance is abysmal. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Mozilla's Hippocritic Oath: "Keep trackers off your trail" ⣾⠁⢰⠒⠀⣿⡁ blah blah evading "tracking technology" blah blah ⢿⡄⠘⠷⠚⠋⠀ "https://click.e.mozilla.org/?qs=e7bb0dcf14b1013fca3820..." ⠈⠳⣄⠀⠀⠀⠀ (same for all links)