Black Friday Last Minute: CPU as a service has come!
tpearson at raptorengineering.com
Fri Nov 24 20:56:21 UTC 2017
-----BEGIN PGP SIGNED MESSAGE-----
Sadly, I'm not sure that this massive leak matters much with e.g. local
governments moving to Windows 10 that is already known to exfiltrate
data. The entire premise of using "<hardware|software>-as-a-Service"
with minimal control and/or privacy seems to be already well established
in the EU, even though it would also seem to directly contradict the
GDPR. I'd love to hear someone from the EU weigh in on how this is
possible from a legal perspective; I don't fully understand it from the
other side of the pond.
Also, if this sort of CPU-as-a-Service is concerning, why not use an ARM
 or OpenPOWER  system that gives you full control? Especially for
those already using libre software the switch is pretty painless. Going
forward one relatively easy way to deal with the problem is to put the
data-slurping proprietary applications on a dedicated x86 machine that's
isolated from the wider Internet as much as possible, and use rdesktop
or similar to connect from a secure machine. Might also be a good idea
to start researching how to make data diodes more accessible to the
"average" libre software user, so that data from the x86 machine can
flow to the non-x86 machines but not vice-versa.
Just my $0.02!
On 11/24/2017 10:19 AM, Giovanni Biscuolo wrote:
> Hi all,
> glad my glamorous title obtained your attention :-D
> I'm joking about Black Friday, I'm _not_ joking about "CPU as a service"
> since the issue I recently labeled in this ML as the "MINIX on ring -3
> discovery" is not clear to at least one of my FSFE-pen-friends, I have be
> more specific
> also, please I would like to know if and eventually how FSFE will address
> this kind of issues when talking with EU or local representatives about the
> "Consumer rights and device sovereignty" policy goal for 2019
> considering what I'm going to show here, we should definitely extend the
> device sovereignty to **all users**: public and private companies,
> governments and all other institutions too, not only consumers (ouch!) :-O
> ...so please also remind EU and local representative that **(part of) their
> (sorry: our) IT systems are also affected** by this serious issue
> Executive summary
> «One Ring to rule them all, One Ring to find them,
> One Ring to bring them all and in the darkness bind them»
> on all Intel processors sold after 2008 there's a running *proprietary*
> variation of the not copyleft free software MINIX 3 (unknown version),
> is running in "ring -3" 
> now we have the proofs that:
> 1. **no** "user facing OS" operating system have final control of the x86
> 2. between the "user facing OS" and the hardware there are at least 2 ½ OS
> kernels (MINIX and UEFI)
> 3. these are proprietary and very likely exploit-friendly
> 4. the exploits can persist, i.e. be written to FLASH, and you can't fix
> 5. the user have _no access_ to the MINIX running in ring -3
> MINIX is running on three separate x86 cores on modern chips, on that OS
> 1. TCP/IP networking stacks (4 and 6)
> 2. File systems
> 3. Drivers (disk, net, USB, mouse)
> 4. Web servers
> please **do not** consider this kind of issues specific to a single
> brand of
> CPUs, since we still do not have proofs but the development path is the
> *** Are you scared yet? If you're not scared yet, maybe I didn't explain it
> very well, because I sure am scared. *** (Ronald Minnich)
> The not so short story
> the fact: on Wednesday, October 25 2017 Ronald Minnich from Google told the
> world about this:
> «With the WikiLeaks release of the vault7 material, the security of the
> (Unified Extensible Firmware Interface) firmware used in most PCs and
> laptops is once again a concern. UEFI is a proprietary and closed-source
> operating system, with a codebase almost as large as the Linux kernel, that
> runs when the system is powered on and continues to run after it boots the
> OS (hence its designation as a “Ring -2 hypervisor"). It is a great
> place to
> hide exploits since it never stops running, and these exploits are
> undetectable by kernels and programs.»
> this article presents a short version of the story:
> I used this for my executive summary ;-)
> the issue is **not** new (known since 2016, at least) and presented many
> times also in FSF/FSFE "circles", eg. here
> and here https://lists.fsfe.org/pipermail/discussion/2016-April/010912.html
> EFF and Matthew Garrett where more specific about the nature of the
> issue on
> May 8 2017 here
> and here
> so: what's new now?!?
> since October 25 (save the date!) what **is** new is that we have a
> scientific proof of the real nature of this _mess_
> ...and we know that Google *is* _desperately_ trying to get rid of this
> issue from their systems *but* they are failing to fully do this
> please enjoy the full Garrett's talk in this video
> he said: "always use coreboot if you can, but if you are stuck with a
> (29:21 of the video) ... libreboot is maybe better, IMHO
> so, ladies and gentlemen I'll introduce you "CPU as a service"
> do we have to accept an EULA?!?
>  https://en.wikipedia.org/wiki/Protection_ring
> what the hell is ring -3 ?!?! who "invented" it?
> where is it documented?
> should we expect to see "ring -9" in the future?
> how we could even allow anyone in the world to implement such a
> perverted environment?
> Discussion mailing list
> Discussion at lists.fsfe.org
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the Discussion