New VM Software Claims To Be 4.5x Faster Than QEMU

[phoronix]

Phoronix: New VM Software Claims To Be 4.5x Faster Than QEMU

Eltechs is preparing to introduce ExaGear Desktop next month as new proprietary software for running Linux x86 software on Linux ARM using their own virtual machine technology...

http://www.phoronix.com/vr.php?view=MTc2NzE

[arrow]

If community support this type of software, that restricts their freedom, the main reason for the GNU/Linux system exist will fade out. Do not support it, you cannot know what this do on your machine. if it is legitimate or have backdoor or trackers. [and, no, this is not "Stallman like", this is the truth guys. Even with many news about projects like PRISM people still using proprietary software, even the instructed peoples who use advanced systems. I'm not talkie about use EMAC or do not connect with internet, just do precautions with it].

[Calinou]

Eltechs is preparing to introduce ExaGear Desktop next month as new proprietary software for running Linux x86 software on Linux ARM using their own virtual machine technology.

It's not like we should trust them? this isn't the first time we see such promises.

[justmy2cents]

4.5x faster only? that's bad. we all know we need to divide with 7 to get reality from commercial ad. 7 is such a magical number

[artivision]

Phoronix: New VM Software Claims To Be 4.5x Faster Than QEMU

Eltechs is preparing to introduce ExaGear Desktop next month as new proprietary software for running Linux x86 software on Linux ARM using their own virtual machine technology...

http://www.phoronix.com/vr.php?view=MTc2NzE

Is there a way to test it with Wine Native on a 4-instruction Atom, versus, Wine ExaGear on a 4-instruction A15?

[Luke]

Trusting a closed hyperviser over closed firmware

In cases where a machine has to be trusted, a closed hyperviser seems to be a worst-case scenario, as the entire OS runs under a closed binary. A closed video driver won't see keyboard output to terminal and should not see the network stack, a closed network binary also should not see the keyboard, a closed keyboard driver must never be used. If all parts of the OS are seen by the same closed binary, however, any and all behaviors could be modified and any attack of or through that binary has easy access to everything.

This is worse than closed firmware in that we are talking far larger blobs that can hide a lot more functions, just like a closed video driver of 50MB can hide a lot more potential "issues" than a 50KB video firmware blob could. Also, most closed driver blobs are for a single piece of hardware and do not see the whole machine from "above" unless malicious from the start or hacked to be do. The exception is the BIOS/UEFI, which is supposed to hand off control to the OS of things like keyboards and video, thus allowing things like opening an encrypted disk without a BIOS call to run the keyboard. Still, Coreboot support for more boards, not more closed hypervisers, is the direction we need to be going in.

If this program is for use with closed operating systems or for machines where trust is not an issue, that's one thing. Running a machine that requires auditablity of code is another thing, however. Just as I do not trust a BIOS keyboard driver for opening encrypted disks in GRUB or Truecrypt(thus prefer our native Cryptsetup), I would advise that this software never have encryption run on top of it, instead using it as an application to an OS that has already been booted from an encrypted disk if this is possible.

[curaga]

Uhm, both closed network and video drivers have full access to your keyboard, screen, and data storage. That's what being in the kernel as a blob gives you.

[Luke]

If so, that's a good reason for rejecting closed video and network drivers.

Uhm, both closed network and video drivers have full access to your keyboard, screen, and data storage. That's what being in the kernel as a blob gives you.

Maybe that's part of the reason the proprietary video drivers have been forced to stay UMS? During the days I played with Nvidia's blob I made sure all encrypted disks were opened before the untrusted blob could be started, which UMS made easy. Thankfully the open-source driver for AMD hardware caught up enough for me to resolve this the right way, by switching back the cards and drivers. I've avoided any network hardware that won't run on open drivers due to the sensitivity of that system for many years.

There are certain extreme security cases (Snowden comes to mind) where even closed firmware can't be trusted. If people distrust a closed video or network driver (as I do in both cases and sure as HELL for network) than they should also distrust a closed hyperviser. We are still a ways from being able to run full functionality on a fully FOSS/no blobs even for firmware distro, but need to go in that direction. Anytime people ask me what things like Trisquel are good for I suggest Snowden-level security, if and only if run over Coreboot. The rest of the time, if backdoors are an issue at all I advise avoiding hardware that requires outright closed drivers, running no closed apps ever, and now I also have to say no closed hypervisers.

One way someone could determine what size closed firmware blob is safe would be this: write a keylogger, a network connection program for it, and another program to activate all of that only when a certain code is recieved by some means, then optimize it for the smallest possible compiled binary. How big is that binary? Anything bigger could contain something similar.

[arrow]

Anytime people ask me what things like Trisquel are good for I suggest Snowden-level security, if and only if run over Coreboot..

Luke, Coreboot have many blob's for now. Try see Libreboot.
I think a secure hardware for now is some ARM systems, like BeableBoard and the, new, Hummingboard from Solid-run (require etna_viv). Just order without wifi and then use Penguin Wireless, and boot from crypto usb with Tails OS.
This is overkill security, but seems to be necessary for people who require this type of guarantee (activists or journalists).
Also.

[Luke]

What is the blob situation in TAILS?

Luke, Coreboot have many blob's for now. Try see Libreboot.
I think a secure hardware for now is some ARM systems, like BeableBoard and the, new, Hummingboard from Solid-run (require etna_viv). Just order without wifi and then use Penguin Wireless, and boot from crypto usb with Tails OS.
This is overkill security, but seems to be necessary for people who require this type of guarantee (activists or journalists).
Also.

When a local police department is the opponent blobs in tails or firmware probably won't matter, maybe this is also true against Secret Service. Against NSA targetted (not mass) surveillance, upstream blobs might be the only way a government agency could get spyware directly into TAILS before anyone downloads it. TAILS is used in life-critical security situations where any exploit could get someone tortured to death or imprisoned for life. If Chelsea Manning had used TAILS over libreboot she would not be in prison, probably not if she had used TAILS on any machine not taken from her US military bosses. If there are blobs in TAILS, from what nations do they originate?

The SD card link is quite interesting, I've always advised use of SD cards on cameras used at protests because the cameras cannot be encrypted and data recovery is trivial if you are trapped with it in a mass arrest. With camera cards, the card and be removed and destroyed quickly, I've heard reports of kids caught in police traps having to smash their own cameras with rocks when their cameras were shooting to non-removable storage. Encryption is worthless if data is captured prior to reaching encrypted storage.