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.
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.
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.
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.
+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.
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.
However, the more important question (also answered in the article and the video) is:
Why do people eat more than they need? Why, when the human body can detect when it has enough nutrients and signal satiety to the brain?
The answer being: Because we've developed foods (by using high fructose amounts in them, through sugar) that block those signal paths. We've perfected foods that we want to crave and that don't make us feel we've had enough, so that we can consume more.
Yes, one possible answer to the caloric equation is: Have a strong will, be hungry and you'll be lean.
The other is: Eat right, and you'll feel satiated after eating exactly the amount that's needed for your health.
And, btw, the equation assumes that all you eat and is digestible gets digested. That obviously isn't true, when overeating a lot of the food just goes through without the nutrients getting extracted. If that wasn't the case, many people would weigh thousands of pounds today.
To answer the question: Fats and proteins, of course. Meatabolizing both produces ATP - directly useful energy. But they're used only when sugar isn't abundant in the bloodstream.
But that isn't the point of the Lustig claim. The point is that there is one specific sugar, fructose, which has a very different buildup. It is a 5-carbon cycle versus a 6-carbon cycle for just about every other sugar. The human body doesn't metabolize fructose well. Specifically when there is plenty fructose available and little energy demand, fructose gets converted directly into harmful fatty acids.
The body obtains fructose from HFCS, regular sugar (sucrose) and fruits, particularly pulp-free juices.
On the other hand, glucose, the more usual 6-carbon sugar is still considered safe. It only doesn't taste at all as good.
And then all the other carbohydrates - starches - are a safe, s 6-carbon-cycle, sources of energy.
Eg. potatoes, rice, pasta, bread.
The current limit on Linux (with 2.6 series) is 8192 CPUs on POWER and 4096 on x86. And there are even a number of non-x86 machines today that reach these sizes in a cache-coherent (ccNUMA) manner that Linux works well on. You still have to be careful with application design, though, because it's fairly easy to hit bottlenecks either in the application or in the kernel that will limit scalability. Most common workloads are already seeing
Inside the IBIS there is two full SATA drive boards, with SandForce SATA controllers, connected to a standard PCIe/SATA RAID controller on the base board.
The only difference to a SATA RAID controller and two regular SSDs is that the cable is in a different place.
It just means the clone will have to be a bit more expensive.
Cloned tags aren't using the same cheap chips that the common passive tags do. An attacker can afford to carry batteries with him and make the tag completely locally powered. Then he has much more powerful electronics at his disposal and can simulate whatever frequency response the original tag had due to its cheap (few cents per tag) design.
This fingerprinting will do no more than to force the attacker to pay a few bucks more to create a clone.
The article assumes that when within a RAID5 array a drive encounters a single sector failure (the most common failure scenario), an entire disk has to go offline, be replaced and rebuilt.
That is utter nonsense, of course. All that's needed is to rebuild a single affected stripe of the array to a spare disk. (You do have spares in your RAID setups, right?)
As soon as the single stripe is rebuilt, the whole array is again in a fully redundant state again - although the redundancy is spread across the drive with a bad sector and the spare.
Even better, modern drives have internal sector remapping tables and when a bad sector occurs, all the array has to do is to read the other disks, calculate the sector, and WRITE it back to the FAILED drive. The drive will remap the sector, replace it with a good one, and tada, we have a well working array again. In fact, this is exactly what Linux's MD RAID5 driver does, so it's not just a theory.
Catastrophic whole-drive failures (head crash, etc) do happen, too. And there the article would have a point - you need to rebuild the whole array. But then - these are by a couple orders of magnitude less frequent than simple data errors. So no reason to worry again.
It's just 75% increased emission rate, not 75% less energy. Continuous wave photoluminiscence doubles, though, according to the article. 75% more efficient would've been four times the output. So not THAT great, but still rather awesome.
Slashdot Mirror
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.
However, the more important question (also answered in the article and the video) is:
Why do people eat more than they need? Why, when the human body can detect when it has enough nutrients and signal satiety to the brain?
The answer being: Because we've developed foods (by using high fructose amounts in them, through sugar) that block those signal paths. We've perfected foods that we want to crave and that don't make us feel we've had enough, so that we can consume more.
Yes, one possible answer to the caloric equation is: Have a strong will, be hungry and you'll be lean. The other is: Eat right, and you'll feel satiated after eating exactly the amount that's needed for your health.
And, btw, the equation assumes that all you eat and is digestible gets digested. That obviously isn't true, when overeating a lot of the food just goes through without the nutrients getting extracted. If that wasn't the case, many people would weigh thousands of pounds today.
To answer the question: Fats and proteins, of course. Meatabolizing both produces ATP - directly useful energy. But they're used only when sugar isn't abundant in the bloodstream. But that isn't the point of the Lustig claim. The point is that there is one specific sugar, fructose, which has a very different buildup. It is a 5-carbon cycle versus a 6-carbon cycle for just about every other sugar. The human body doesn't metabolize fructose well. Specifically when there is plenty fructose available and little energy demand, fructose gets converted directly into harmful fatty acids. The body obtains fructose from HFCS, regular sugar (sucrose) and fruits, particularly pulp-free juices. On the other hand, glucose, the more usual 6-carbon sugar is still considered safe. It only doesn't taste at all as good. And then all the other carbohydrates - starches - are a safe, s 6-carbon-cycle, sources of energy. Eg. potatoes, rice, pasta, bread.
Well, well, I hit the Submit button too soon. Anyway, most common workloads are already seeing decreasing benefits around 32 parallel threads.
The current limit on Linux (with 2.6 series) is 8192 CPUs on POWER and 4096 on x86. And there are even a number of non-x86 machines today that reach these sizes in a cache-coherent (ccNUMA) manner that Linux works well on. You still have to be careful with application design, though, because it's fairly easy to hit bottlenecks either in the application or in the kernel that will limit scalability. Most common workloads are already seeing
http://en.wikipedia.org/wiki/End-to-end_auditable_voting_systems I think the system described in the TED talk is the Prêt à Voter system.
Inside the IBIS there is two full SATA drive boards, with SandForce SATA controllers, connected to a standard PCIe/SATA RAID controller on the base board.
The only difference to a SATA RAID controller and two regular SSDs is that the cable is in a different place.
It just means the clone will have to be a bit more expensive.
Cloned tags aren't using the same cheap chips that the common passive tags do. An attacker can afford to carry batteries with him and make the tag completely locally powered. Then he has much more powerful electronics at his disposal and can simulate whatever frequency response the original tag had due to its cheap (few cents per tag) design.
This fingerprinting will do no more than to force the attacker to pay a few bucks more to create a clone.
The article assumes that when within a RAID5 array a drive encounters a single sector failure (the most common failure scenario), an entire disk has to go offline, be replaced and rebuilt.
That is utter nonsense, of course. All that's needed is to rebuild a single affected stripe of the array to a spare disk. (You do have spares in your RAID setups, right?)
As soon as the single stripe is rebuilt, the whole array is again in a fully redundant state again - although the redundancy is spread across the drive with a bad sector and the spare.
Even better, modern drives have internal sector remapping tables and when a bad sector occurs, all the array has to do is to read the other disks, calculate the sector, and WRITE it back to the FAILED drive.
The drive will remap the sector, replace it with a good one, and tada, we have a well working array again. In fact, this is exactly what Linux's MD RAID5 driver does, so it's not just a theory.
Catastrophic whole-drive failures (head crash, etc) do happen, too. And there the article would have a point - you need to rebuild the whole array. But then - these are by a couple orders of magnitude less frequent than simple data errors. So no reason to worry again.
*sigh*
It's just 75% increased emission rate, not 75% less energy. Continuous wave photoluminiscence doubles, though, according to the article. 75% more efficient would've been four times the output. So not THAT great, but still rather awesome.
Actually, the article on Medical News is about a different, yet also remarkable anti-cancer drug from the same company.