[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automatic downloading of non-free software by stuff in main

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.

⢀⣴⠾⠻⢶⣦⠀ 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)

Reply to: