Sun Plans Security Coprocessor For New Ultrasparc 59
angry tapir writes "At the Hot Chips conference at Stanford University, Sun presented plans for a security accelerator chip that it said would reduce encryption costs for applications such as VoIP calls and online banking Web sites. The coprocessor will be included on the same silicon as Rainbow Falls, the code name for the follow-on to Sun's multi-threaded Ultrasparc T2 processor."
Encryption != Security (Score:5, Insightful)
A chip to offload encryption is a good thing, however it is not a "security chip". Security is a broad topic that this chip will barely touch.
Re:Encryption != Security (Score:3, Insightful)
Keep it simple.
Their target market is VoIP and banking websites, where SECURE Sockets Layer/Transport Layer SECURITY rule. (Okay, with VoIP they're more of a pipe dream, but work with me here...") Those are what the chips are designed to accelerate by offloading. VoIP *does* (or can) use MD5/SHA hashing, which is also something accelerated by the chip.
Thus, calling it a SECURITY accelerator doesn't confuse the people that sign the checks, because SECURE and SECURITY are what they're already using for their sites. You don't have to bother explaining the difference to them, because it would just confuse them. The people that know the difference between security and encryption won't need to have it explained to them, so why bother? They're just going to download the spec sheet anyway and turn to the grid on back, instead of the executive blurb on front with shiny, happy executive-type people.
Re:Unanswered Questions (Score:3, Insightful)
"This history of co-processors for specific jobs has never been a very happy or long-lived one."
Seems to me that GPU's have been around for a pretty long time, are generally pretty successful at what they do, and people are more-or-less happy with them. Perhaps, though, they are the exception that proves the rule.
Re:Unanswered Questions (Score:5, Insightful)
How will current software interact with this chip and be transparent for current applications? Software support in things like IPSec libraries for this hardware is going to be important.
This is Sun. They sell the whole stack - computer, OS, compiler, and so on. You can bet that Sun Java running on Sun Solaris, running on a Sun UltraSPARC will use the coprocessor. The Solaris version of OpenSSL almost certainly will too.
Is this a response to the Sparc's lack of CPU grunt compared with other processors? If it is then it's going to make Sparc even more expensive relative to the competition.
Not sure how you figure that. Something like the OMAP3530 can decode H.264 in a tiny power envelope compared to something like a Core 2, and yet costs much less. Why? Because it uses dedicated silicon for the decoding. General purpose processors use much more power and, for the same transistor budget run much more slowly than dedicated hardware. If the typical workload for a T2 is very crypto-heavy then adding a dedicated a crypto coprocessor will use less power and give better performance than adding another core. This is why most ARM chips include a number of coprocessors for workloads that are common in handhelds.
It's easier to update software than it is to update silicon or chips. How will this approach and this chip fare in a few years when technology and software has moved on?
But it's slower to replace standards than either, and encryption standards require years of peer review before they are approved.
This history of co-processors for specific jobs has never been a very happy or long-lived one.
Yup, no modern CPUs contain on-chip floating point or vector coprocessors. Well, none except for all of them. And no modern computers contain graphics coprocessors.
It looks like a way of making up for the inherant lack of grunt on the Sparc platform, so maybe it will reduce encryption costs as far as that platform is concerned.
Not sure what you mean by 'inherent lack of grunt'. For highly parallel workloads (e.g. web serving, lots of database workloads), there isn't much that beats a T2 in terms of throughput at the moment, and nothing that comes close in terms of performance per Watt. Offloading to a coprocessor improves power efficiency even more, which is something that people running data centres care a lot about.
Re:Encrypt in the Cloud (Score:2, Insightful)
Why would you want a dedicated chip for this when cloud computing is in fashion? Offload your burdensome encryption work.
Yeah, this is *exactly* the sort of hardware that the "cloud" providers run.
Re:but is Oracle interested? (Score:3, Insightful)