Ok, so the next step in the game is a VPN with a built-in transparent TCP (or deeper) proxy at the VPN provider end. That'll take care of the latencies.

I have to admit that due to where I work, I simply use openSUSE. With 13.2, it's all just a matter of selecting the right options in the installer.

Blocking the firmware update command is certainly a good idea. Even if you protect your OS from malware coming from the drive, you can still have an unbootable machine, thanks to Secure Boot or completely corrupted firmware.

Don't use Microsoft keys in your UEFI secure boot setup, then. Use your own.

Since the CD-ROM drives today have handle many formats from old CD to latest BluRay, they have in fact a fairly capable (and upgradable, remember the region wars?) firmware and a CPU on them.

Your example #1 doesn't work. There is no point in the Secure Boot boot process which wouldn't be cryptographically verified. The shims are signed and verified, even the MOKManager is. So the malicious code can run on the drive, but will not affect what is running on the main CPU and the main CPU will not leak any key data to the drive.

For your example #2: I do not care if random bits of my encrypted data remain in a hidden part of the drive. That will happen on SSDs anyway.

Most Secure Boot implementations let you use your own keys. And building your own shim is just a matter of typing 'make'.

Of course the UEFI code cannot bypass the drive firmware. From the point of view of secure boot, the boot media is untrusted, and thus it doesn't care whether there is any malicious code in the drive firmware. It simply verifies that anything it loads from there is signed and thus uncompromised. If the bootloader or kernel were tampered with, Secure Boot will refuse to boot.

Actually, the much hated Secure Boot (with the shim loader, MOK, and GRUB2), combined with full disk encryption (for example using LUKS), and in filesystem compression (btrfs2) can quite nicely protect you from anything that a malicious firmware in a harddrive could do. The firmware will only ever see encrypted data passing through it, except for when loading the bootloader and the kernel, which will both be cryptographically verified by UEFI. The in-filesystem compression is there to compensate for the compression SSD drives normally do themselves to gain additional speed that will be impossible to do that on encrypted data.

Sure, this basically converts the problem to trusting the main BIOS (UEFI), but that's something you have to solve in any case.

You might want to examine the MOK concept that SUSE has implemented. It allows for custom executables that are checked against a local key.

Regarding configuration, that is outside of the scope of Secure Boot. Its purpose isn't a full system attestation, it's limited to preventing executing untrusted code in kernel space. That alone is of value, as it makes installing persistent and invisible rootkits much much harder. Not impossible, of course - as long as software can have bugs, no security technology can be perfect.

(working for SUSE ...)

+1 Funny. Anyway, SUSE has grown much beyond Nürnberg, even though the HQ has been moved back to Nürnberg recently. I personally am located in Prague, but we have employees on all continents with the exception of Africa and Antarctica and I'm not sure how long even that exception will hold. ;)

Novell has been acquired by The Attachmate Group (http://attachmategroup.com/) and is now privately owned and the original Novell businesses now form most of what The Attachmate Group is.

TAG is now operating four businesses: Attachmate - their original business, NetIQ - the systems/network/identity/compliance/security-management company, where the Novell Managewise, Zenworks, identity manager, platespin, orchestrator, etc, etc, products are a significant part of the portfolio, then Novell - with the "true" Novell products like NetWare and GroupWise, and finally SUSE, with the Linux products.

And TAG is doing rather well overall.

Regarding the IP, you could've seen in the news that this was abould the old Novell patent warchest. Patents that Novell owned for defense purposes, sort of an atomic stockpile for mutual assured destruction. They've been purchased by a consortium created by Microsoft, Apple, Oracle and EMC and safely stored in an equivalent of a nuclear waste storage facility until their danger to the members of the consortium expires.

And nothing of value to Novell was lost - TAG retained the IP relevant to Novell's, NetIQ's and SUSE's present products. You may argue that with a reduction of the number of warheads TAG is more vulnerable. Novell/SUSE/TAG are still a (contributing) member of the OIN and thus believes it doesn't need to own such a huge stockpile itself.

... we're hiring. Are you any good?

Actually, should you study the history and evolution of Slavic languages, you'd learn that it in fact means "swampy country", the root 'bel', now meaning white in many Slavic languages was used to describe swamps instead a thousand or so years ago.

No. The reheater system uses the waste heat from the AC to reheat the air back to reasonable indoor temperatures. There is no extra energy needed for heating, in fact less energy will be consumed if the output temperature is higher: The AC condenser will get better cooling and the efficiency will increase.