This seems to be an unfortunate relic from the fight against the clipper chip.
Buying hardware that you don't own and control is a big problem, but that doesn't mean all methods of securing the boot process are evil. The important bit is that it's the owner of the hardware that's in control of the keys, and that (s)he can retain sole control of the signing keys if desired.
No, it's an ongoing contour. The companies that are interested in creating secure boot chains are uninterested in openly documenting the details. I presume both aspects come from the single-minded business desire of centralized control.
The Snowden leak claimed that the NSA had special Intel chips, but no one has ever claimed Intel did a special production run. However, if they stole Intel's signing keys and internal documentation, they could just reflash the existing chips and Intel would not need to know a thing about it. Anyone who gets their hands on that information would be able to do the same and there is not a thing you can do about it beside using hardware where that is not possible.
I think we're in agreement then. Intel's system does not meet the criteria I set forth in the post you're replying to (since there is only one key, and it's generated out of the owners control). So that's a bad solution. If there were some way for a physically present user to set a new firmware signing key, that would get the benefit without having to throw out any attempt to secure the boot process.
Of course, intel's microcode is not open for scrutiny, so the point is moot there (what would you sign instead?)
The linked project states that having no way to lock the boot process is a benefit. I disagree that it's a feature to advertise, because it's possible to implement in such a way that the user retains complete control. Pointing out bad implementations is not a good answer to that.
The ME is an embedded device that has its own independent CPU and operating system. Whether Secure Boot is possible is tangential to that. Secure Boot is as relevant to security here as lowering the anchor on the titanic after hitting that iceberg. Whether the measure is in place or not does not actually fix things.
> Buying hardware that you don't own and control is a big problem, but that doesn't mean all methods of securing the boot process are evil.
Hear hear! Why are technology people, who are supposedly intellectual, thoughtful people, so prone to unthinking political knee-jerk?
As much as such technology can suck for individual's interests when turned against them, there is just as much potential for benefit to individual interests if the technology can be aimed 180 degrees the other way.
What if all information corporations possessed about you as an individual were protected through some trusted execution environment, with only publicly vetted code operating on it? What if any individual could meaningfully revoke access to their information when corporations turned out to be evil?
It's much easier to add such a scheme to any platform than removing it when the vendor decided for you that this is what you want. If you want to lock the box down, put the firmware in flash, clip the ~WP pin, pour epoxy on it.
I guess the Raptor Eng folks aren't opposed to adding something more flexible to a later iteration (I'd propose securely measuring the firmware into some trusted external store in the style of TPM1.x and working from there), but for now the project is about helping undo the damage done to the ecosystem by providing an old-style "all open" platform again.
Not sure if it'd work but if the blob is to be loaded on the card, it would be just like a x86 setup - it should work as long as the host part is compilable for POWER.
Interesting... but I see only two reasons I'd get it at that price. If I actually expect cover channel data exfiltration, or really don't trust in generating crypto keys on standard Intel architecture. But the second one is solved by HSMs too.
So does anyone know why one would prefer this board?
> If I actually expect cover channel data exfiltration, or really don't trust in generating crypto keys on standard Intel architecture. But the second one is solved by HSMs too.
The HSMs I've worked with were linux boxes, running on standard Intel hardware with some added tamper protection sensors and a battery for the EC. They even used OpenSSL behind the scenes. I'm sure they don't all work that way, but it'd be a mistake to think that HSMs are all unicorns and rainbows and immune to these kinds of attacks.
I'd like to know that they consider to be sufficient interest to justify a production run. This is a really niche project, and $3000 seems quite low for a one-off motherboard made in a couple of hundred units.
Hopefully these guys have worked out the math, I've just noticed that most people, especially software people, seriously underestimate the cost of producing hardware in small quantities.
I think there might be enough interest in HPC. A few of the big upcoming supercomputing projects are going to be based on POWER8. I'd guess a decent number of people buying them are HPC types that want to start experimenting with porting and tuning for those upcoming systems.
I'm just speculating, but I hope they already had enough demand to justify what is definitely a niche product.
Thanks, that sounds a lot more realistic than what I had in mind. Hopefully they'll get enough interested people to commit, it'd be great to have a choice in workstation architecture again.
I realize they are two differ et domains of expertise, but if I'm paying someone $3000 for a computer, shouldn't they at least be able to hire a competent web designer?
This is atrocious - floating menus and text blocks that move and cover over the main text when you try to zoom, and no responsive design so you have to zoom in mobile. Sorry, I'm not going through the hat much work to read your site.
Personally, I'd rather they just went with plain html and no attempt at presentation of any kind. Cheaper and the viewer gets to decide on font size/styles &c.
But, no, with hardware this specialised, those who have a need for it won't mind what the page looks like.
I like it as competition to Intel in the desktop space for power users. Workstation market used to be fun with interesting machines from SGI, IBM, Sun, HP, Compaq, and so on. SGI's blew people away with graphics & NUMA architectures. DEC/Compaq's Alpha's could be microcoded for concurrency or performance using regular assembly via a scheme called PALcode. HP PA-RISC and SGI's Itanium systems have memory keying scheme for access control, originally in IBM mainframes, that constrains attackers a bit if used well. The RISC systems supported more programming models without the efficiency hit of x86's that assumed stacks and had little registers. Unfortunately, x86 was very good at running C and x86 code becoming more prevalent. Plus the Microsoft partnership. So, everything else pretty much disappeared.
Anyway, it would be cool to have options. Especially with security extensions for code in the CPU and/or open CPU's. Unfortunately, this really ain't it. People are better off licensing or directly using Gaisler's 4-core SPARCs with security extensions a la Cambridge's CHERI, SecureCore, or Hardbound. We'd have fast, open CPU's w/ open firmware w/ open OS's w/ support at CPU level for confidentiality and/or integrity. That is how you begin on a secure workstation. ;)
I'm super excited about CHERI. ... But the fastest CHERI implementation now or likely in the next couple years is orders of magnitude slower than the offerings from AMD and Intel. (Not fundamentally-- but primarily as a product of maturity and development)
There are many applications where I'd gladly take a 100 fold performance (or energy efficiency loss) for the kind of security improvement that CHERI gives. But there are also many applications where I (and importantly, other people who care less about security than I do) cannot afford those sorts of reductions.
Meanwhile, the fast machines available to us all have opaque, cryptographically locked, and seemingly often vulnerable supervisory code running on them.
To make an impact OpenPower solutions need merely be better in some respect (avoiding the secret supervisory code) and not too worse in others. It might be a tougher call if MPX were already a practical reality or if SGX weren't being held back by ridiculous licensing.
"But the fastest CHERI implementation now or likely in the next couple years is orders of magnitude slower than the offerings from AMD and Intel. (Not fundamentally-- but primarily as a product of maturity and development)"
That's due to a lack of demand. The ultimate problem for high security. Gaisler's stuff is already implemented. The RISC-V Rocket core is 1.4Ghz. Basic checks like in SAFE's atomic groups have single-digit, percentage effects on performance. The mods can be tweaked to give desire performance. Worst I've seen was 70-80% loss on a prototype designed for research rather than performance on most memory-intensive stuff. Not 100x or anything.
"Meanwhile, the fast machines available to us all have opaque, cryptographically locked, and seemingly often vulnerable supervisory code running on them."
Definitely improvements to be had in things with open firmware and such. POWER and SPARC have had that for quite a while via Open Firmware standard. SPARC and MIPS have open implementations with SPARC not requiring an ISA license. Not sure about availability of server-grade POWER implementations or licensing costs. Definitely need more to work with in that area.
"To make an impact OpenPower solutions need merely be better in some respect (avoiding the secret supervisory code) and not too worse in others."
I hope that's true. What killed it before was legacy effect: key apps or capabilities that worked on x86 didn't on alternatives. Even Apple abandoned PPC. Only one doing it on desktops are the Amiga systems.
For common use-cases, we need to port Flash, JS JIT's, ASM-optimized codecs... all sorts of things to POWER to achieve parity. I've always liked POWER better than x86. It's just that users use apps not ISA's. That's why x86 has holding power.
So, it's literally gotta be users who don't need games, fast browsers, CAD, etc. It has to be people using native apps written in portable code leveraging components written similarly. Even better if it's multi-threaded or benefits from POWER's accelerated instructions. How many use-cases does that represent for desktop users?
It isn't hard to create new ports, you just have to have the source code, but everyone uses proprietary software so new ports have zero chance outside the open source world.
The in kernel, free radeon drivers are good and supported by amd. They should work on little-endian systems, which all of the newer POWER systems are[0].
Unforunately big-endian amd/radeon support seems to have bit rotted. So if that g4 laptop has an amd device accelerated video might not work. I'm not sure how well nouveau works for nvidia devices.
There have been some discussions about this problem on the debian-powerpc mailing list so check out the archives if you're interested. Some of us also hang out on OFTC/#debianppc.
Sound support should be the same as intel and printers are handled by userland so that shouldn't be a problem with most printers that work with linux.
JIT support for ppc64el is good because of IBM support. It has jdk and v8 ports.
Define "secure". In too many cases it is a marketing buzzword. At some point those of us who are security professionals really need to get serious about pushing for some standard language and certification in this space. I'd love to see a rating system which makes it clear which attacks this platform can defend agains. As an example, is it only secure if locked in a secure facility, protected from physical access or can it exist in a physically hostile environment? How much of it can be exposed to an attack surface before it's not secure? At this moment I'm aware of several physical layer attacks that this would absolutely fail to protect against so I question why exactly this gets me anything more than any other hardware platform.
In a world of millions of networked devices it seems redundant to classify any one single element as "secure". The secure device cannot possibly trust any other device, and those devices in turn cannot trust the secure device. By necessity we use a combination of different systems, and any one rogue system could undermine the rest. The only way to make that safe is to understand how different systems interact and ensure they are sand boxed from one another. This is particularly difficult when a single machine can have several processors running their own platform.
I have a secret dream of having a secure "big data in a box" solution based on Linux / GPUs (likely nVidia) and lots of storage (like 8 6TB drives in Raid z2). This processor and motherboard would be fine if it had more IO (4-6 16x slots) and onboard 10Gbe. Right now seems like this is still a pipe dream.
So, honest question, what kind of workloads and tasks would a box built from this motherboard be good for? Video or audio editing? CAD? 3d Rendering? Programming? Assuming the hardware is up to the task, cool, now what about the software?
In my years working IT, it seems to me that by and large, the professional software for tasks you'd throw an expensive workstation at (CAD, 3d rendering, etc) has by and large migrated to being targeted for x86 Windows boxen, because that's what their clients have. For some tasks (audio/video production) some software still targets macs, but that's about it from what I've seen.
I'm tempted to try to pick up a couple of these to see if I can turn them into something useful, but the rare power user or hobbyist doesn't seem like enough demand to sustain development of a product like this, as cool as it might be. Is there some niche somewhere that I am not aware of where something like this would be useful? Enough for someone to buy enough of these to sustain further development and production?
I'm actually pretty interested in this as a potential form of cheap(ish) HPC. I do a lot of stellar simulations and other computational astrophysics stuff, I think a couple of these might be able to stand in when I don't necessarily feel like dealing with the campus supercomputer for a small task. Although in terms of marketability, I'd say that products like these might fulfill the gap between traditional farms <-> giant supercomputers.
TL;DR Performs similarly to current E3/E5 xeon CPUs, and the 64 cores (57 tested) are great for parallel workloads. There's some applications (OpenSSL) missing POWER8-specific optimization.
58 comments
[ 5.0 ms ] story [ 122 ms ] threadNot really a "secure" workstation if you can't have a secure bootchain. An open, secure platform would allow you to fuse your own root key.
Buying hardware that you don't own and control is a big problem, but that doesn't mean all methods of securing the boot process are evil. The important bit is that it's the owner of the hardware that's in control of the keys, and that (s)he can retain sole control of the signing keys if desired.
https://libreboot.org/faq/#intel
The Snowden leak claimed that the NSA had special Intel chips, but no one has ever claimed Intel did a special production run. However, if they stole Intel's signing keys and internal documentation, they could just reflash the existing chips and Intel would not need to know a thing about it. Anyone who gets their hands on that information would be able to do the same and there is not a thing you can do about it beside using hardware where that is not possible.
Of course, intel's microcode is not open for scrutiny, so the point is moot there (what would you sign instead?)
The linked project states that having no way to lock the boot process is a benefit. I disagree that it's a feature to advertise, because it's possible to implement in such a way that the user retains complete control. Pointing out bad implementations is not a good answer to that.
Hear hear! Why are technology people, who are supposedly intellectual, thoughtful people, so prone to unthinking political knee-jerk?
As much as such technology can suck for individual's interests when turned against them, there is just as much potential for benefit to individual interests if the technology can be aimed 180 degrees the other way.
What if all information corporations possessed about you as an individual were protected through some trusted execution environment, with only publicly vetted code operating on it? What if any individual could meaningfully revoke access to their information when corporations turned out to be evil?
I guess the Raptor Eng folks aren't opposed to adding something more flexible to a later iteration (I'd propose securely measuring the firmware into some trusted external store in the style of TPM1.x and working from there), but for now the project is about helping undo the damage done to the ecosystem by providing an old-style "all open" platform again.
Libre graphics hardware is quite rare, virtually everything on the market requires binary firmware blobs.
(As do all mass storage devices…)
So does anyone know why one would prefer this board?
The HSMs I've worked with were linux boxes, running on standard Intel hardware with some added tamper protection sensors and a battery for the EC. They even used OpenSSL behind the scenes. I'm sure they don't all work that way, but it'd be a mistake to think that HSMs are all unicorns and rainbows and immune to these kinds of attacks.
Hopefully these guys have worked out the math, I've just noticed that most people, especially software people, seriously underestimate the cost of producing hardware in small quantities.
I'm just speculating, but I hope they already had enough demand to justify what is definitely a niche product.
This is atrocious - floating menus and text blocks that move and cover over the main text when you try to zoom, and no responsive design so you have to zoom in mobile. Sorry, I'm not going through the hat much work to read your site.
I do agree though.
But, no, with hardware this specialised, those who have a need for it won't mind what the page looks like.
Anyway, it would be cool to have options. Especially with security extensions for code in the CPU and/or open CPU's. Unfortunately, this really ain't it. People are better off licensing or directly using Gaisler's 4-core SPARCs with security extensions a la Cambridge's CHERI, SecureCore, or Hardbound. We'd have fast, open CPU's w/ open firmware w/ open OS's w/ support at CPU level for confidentiality and/or integrity. That is how you begin on a secure workstation. ;)
There are many applications where I'd gladly take a 100 fold performance (or energy efficiency loss) for the kind of security improvement that CHERI gives. But there are also many applications where I (and importantly, other people who care less about security than I do) cannot afford those sorts of reductions.
Meanwhile, the fast machines available to us all have opaque, cryptographically locked, and seemingly often vulnerable supervisory code running on them.
To make an impact OpenPower solutions need merely be better in some respect (avoiding the secret supervisory code) and not too worse in others. It might be a tougher call if MPX were already a practical reality or if SGX weren't being held back by ridiculous licensing.
That's due to a lack of demand. The ultimate problem for high security. Gaisler's stuff is already implemented. The RISC-V Rocket core is 1.4Ghz. Basic checks like in SAFE's atomic groups have single-digit, percentage effects on performance. The mods can be tweaked to give desire performance. Worst I've seen was 70-80% loss on a prototype designed for research rather than performance on most memory-intensive stuff. Not 100x or anything.
"Meanwhile, the fast machines available to us all have opaque, cryptographically locked, and seemingly often vulnerable supervisory code running on them."
Definitely improvements to be had in things with open firmware and such. POWER and SPARC have had that for quite a while via Open Firmware standard. SPARC and MIPS have open implementations with SPARC not requiring an ISA license. Not sure about availability of server-grade POWER implementations or licensing costs. Definitely need more to work with in that area.
"To make an impact OpenPower solutions need merely be better in some respect (avoiding the secret supervisory code) and not too worse in others."
I hope that's true. What killed it before was legacy effect: key apps or capabilities that worked on x86 didn't on alternatives. Even Apple abandoned PPC. Only one doing it on desktops are the Amiga systems.
For common use-cases, we need to port Flash, JS JIT's, ASM-optimized codecs... all sorts of things to POWER to achieve parity. I've always liked POWER better than x86. It's just that users use apps not ISA's. That's why x86 has holding power.
So, it's literally gotta be users who don't need games, fast browsers, CAD, etc. It has to be people using native apps written in portable code leveraging components written similarly. Even better if it's multi-threaded or benefits from POWER's accelerated instructions. How many use-cases does that represent for desktop users?
Debian has more than 96% of packages compiled for POWER and IBM is working on porting the reset and optimising things.
https://buildd.debian.org/stats/ https://wiki.debian.org/ppc64el
It isn't hard to create new ports, you just have to have the source code, but everyone uses proprietary software so new ports have zero chance outside the open source world.
That would be cool because one of my disposables is an old Mac laptop with G4 CPU. Getting modern Linux distro on it would be cool.
Unforunately big-endian amd/radeon support seems to have bit rotted. So if that g4 laptop has an amd device accelerated video might not work. I'm not sure how well nouveau works for nvidia devices.
There have been some discussions about this problem on the debian-powerpc mailing list so check out the archives if you're interested. Some of us also hang out on OFTC/#debianppc.
Sound support should be the same as intel and printers are handled by userland so that shouldn't be a problem with most printers that work with linux.
JIT support for ppc64el is good because of IBM support. It has jdk and v8 ports.
[0] https://wiki.debian.org/ppc64el
"JIT support for ppc64el is good because of IBM support. It has jdk and v8 ports."
...I didn't even think about. Of course IBM's components might be usable for the desktop. ("Doh!") Thanks for the info.
https://www-01.ibm.com/support/knowledgecenter/linuxonibm/li...
The page above lists RHEL, SLES (the commercial variant of OpenSUSE), Ubuntu in the context of servers.
https://wiki.debian.org/ppc64el
More than 96% of Debian is compiled for it and hopefully works ;)
Computer hardware can be used to run computer software.
In my years working IT, it seems to me that by and large, the professional software for tasks you'd throw an expensive workstation at (CAD, 3d rendering, etc) has by and large migrated to being targeted for x86 Windows boxen, because that's what their clients have. For some tasks (audio/video production) some software still targets macs, but that's about it from what I've seen.
I'm tempted to try to pick up a couple of these to see if I can turn them into something useful, but the rare power user or hobbyist doesn't seem like enough demand to sustain development of a product like this, as cool as it might be. Is there some niche somewhere that I am not aware of where something like this would be useful? Enough for someone to buy enough of these to sustain further development and production?
http://www.phoronix.com/scan.php?page=article&item=talos-wor...
TL;DR Performs similarly to current E3/E5 xeon CPUs, and the 64 cores (57 tested) are great for parallel workloads. There's some applications (OpenSSL) missing POWER8-specific optimization.
https://wiki.debian.org/FPGA