Wait until he finds out about microcode!
umm...he already knows about microcode obviously. Libreboot does not allow microcode updates.
Freedom and security issues on x86 platforms
231–240 of 282 posts
Re: Freedom and security issues on x86 platforms
#232I've been looking into this recently. Basically, the things mentioned on the text, made free software bios and firmwares impossible, some of the free software projects that exist now are mostly "binary blobs loaders", having more binary blob than free software code running. There is some good analysis on why even Intel can't fix this if they wanted to, unless they stopped shipping some features entirely, their Intel…
Also planned obsolescence by gradually slowing the machine over time.
That would be far too provable and suspicious, since it'd have to be done 24/7 and would rule out the heisenbug route.
If you were to do such a thing, you'd do it by making the machine overclock itself too much occasionally (after the 'artificial use-by date' has passed, thereby incurring physical damage at random intervals. Although really, it would be easy to do without blob, too, if you're doing the design of the physical chip.
Re: Freedom and security issues on x86 platforms
#233Earlier quoted context omitted.
As it is right now you're giving up your liberty (debugging/inspecting/tinkering) in exchange for security. That's generally a bad trade. Sadly one that many people are willing to make until it bites them. It would be a lot better if secure mode had its own supervisor mode that worked through a master key that could be installed at boot time.
It's really a question of who you trust. There are lots of scenarios where you might trust the developer of a particular piece of software more than you trust the entire software stack running on your PC. This is especially true for a nontechnical / casual / grandma user, who has no hope of ever auditing or even having more than a vague idea of what's running on their computer at a given time, and probably is running…
None of that justifies the absence of an ultimate user override.
There is no need to give up freedoms for that security.
Only when DRM comes into play you can really explain why the user is not in control here.
Re: Freedom and security issues on x86 platforms
#234Earlier quoted context omitted.
It's called covert channels. It could be done by flipping some unused/ignored bits in ip4/tcp headers in a stream of traffic that goes past a collection point.
But this is still easily visible with wireshark, right? Don't you think we'd have discovered this by now?
Exfiltration of logged keystrokes and other data is possible through introducing network packet jitter by the ME. This is virtually undetectable.
https://events.ccc.de/congress/2013/Fahrplan/events/5380.htm...
Re: Freedom and security issues on x86 platforms
#235Hmm. OK, I have two questions - maybe somebody here has answers: 1) "...these proprietary blobs could easily contain code to exfiltrate encryption keys, remotely activate microphones and cameras..." This seems basically impossible to actually achieve in reality though, because there will still associated network traffic that can be sniffed, and will have been by now, right? I mean, it is plausible that somehow we all…
Re. 1 - depends what the data and the receiver looks like and what is your end goal. If you want to "phone home" over normal network, then sure, it's going to be obvious. But if you want to preserve all the generated private keys and just send them over RF on bootup using the chip itself as an antenna? That's in the easy territory.
Re: Freedom and security issues on x86 platforms
#236Earlier quoted context omitted.
"I'd use Gaisler's immediately because it's fully open and already FPGA qualified. I'd then buy a good FPGA board. Then I'd run it on there. It would probably run like a multi-core version of my old Pentium II." Sorry, let me clarify ... Pretend you have three kids. But at the same time you'd like to tinker with a fully open system from loader on up. Is there an old sun sparc that would make rms happy that I could bu…
I think the last generation of SPARC-based workstations in wide production were the Ultra 45s. They were made until 2008, according to Wikipedia [1]. They sell for surprisingly high prices [2], for an almost-decade-old computer, on eBay. You could probably get an old Apple PowerPC-based system for considerably less than that, and a LibreBoot-compatible x86 system for even less, but they do exist if you wanted to play…
Oh, so any sun sparc workstation of that era would work.
Understood - thank you.
Re: Freedom and security issues on x86 platforms
#237Earlier quoted context omitted.
To your 1): there would indeed be network traffic, but how many people have a machine they can truly trust capturing and analysing enough of the traffic going in and out of their LAN? Unfortunately there are few, if any, machines we can truly trust.
But don't we only need a few to catch them once? And don't we have at least a few?
[deleted]
Re: Freedom and security issues on x86 platforms
#238Earlier quoted context omitted.
To your 1): there would indeed be network traffic, but how many people have a machine they can truly trust capturing and analysing enough of the traffic going in and out of their LAN? Unfortunately there are few, if any, machines we can truly trust.
But don't we only need a few to catch them once? And don't we have at least a few?
And remember that Intel AMT etc are targeted at the same kinds of large organizations.
Re: Freedom and security issues on x86 platforms
#239It seems superficial to concentrate on a few kilobytes of binary blobs as a security issue when millions of logic gates are also hidden from user scrutiny by design in most computers. That the number of people you have to trust now includes firmware developers in addition to hardware designers is a small movement in the scheme of things, though it may be a movement in an undesirable direction.