×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Sun Plans Security Coprocessor For New Ultrasparc

Soulskill posted more than 4 years ago | from the a-good-processor-knows-how-to-delegate dept.

Encryption 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

59 comments

First post (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#29202131)

Fuck goatse, go to Cute Overload [cuteoverload.com] instead.

first fail (1)

Adolf Hitroll (562418) | more than 4 years ago | (#29202231)

Do you masturbate often to cute-overload front page, or is it upon slashdot fake hope of first posting?
or is it just in front of your basement's sink?
well, wait: don't answer: I don't care.
Kill yourself.

Math Coprocessor (0)

spacemky (236551) | more than 4 years ago | (#29202137)

I'm ok with the security chip as long as it also has a Math Coprocessor. First post?

Why Coprocessor? (0)

Anonymous Coward | more than 4 years ago | (#29203995)

Why use a seperate chip? Nano is an X86 that can do encriptions faster than anything costing more that 10 times as much. Easier ant the code if free. Wait.......I get it now!

Encryption != Security (4, Insightful)

GrenDel Fuego (2558) | more than 4 years ago | (#29202145)

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 (2, Informative)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#29202189)

But understanding is hard and buying "solutions" is easy, so the cryptographic coprocessor is now a security chip. So saith marketing.

Re:Encryption != Security (2, Insightful)

chill (34294) | more than 4 years ago | (#29202391)

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:Encryption != Security (2, Informative)

TheRaven64 (641858) | more than 4 years ago | (#29203011)

Except that there are chips with security coprocessors, which are not the same thing. Most modern ARM chips, for example, include a trust zone feature which only runs signed code and prevents tampering (it's used, for example, to make it impossible to unlock a device without entering a passcode). Cryptographic acceleration on-chip isn't particularly novel either; the Via C-series chips have done it for a while, and OpenSSL will use. That's not to say it isn't useful; especially in a data centre where power usage matters a lot, having dedicated silicon for common operations can boost your performance-per-Watt numbers a huge amount (compare H.264 encoding on an i.MX515 to a Xeon, for example).

Re:Encryption != Security (2, Informative)

chill (34294) | more than 4 years ago | (#29203377)

Again, the people that understand the difference don't need it explained to them. Those that don't -- the ones that sign the checks -- will just be confused. Now, even more so if you bring up trusted execution.

Sun's been doing encryption offload since well before Via added it on their chips. This is just a new revision of their crypto accelerator board. Personally, I've been using these [soekris.com] for years. Cheap and effective.

Re:Encryption != Security (1)

Chris Mattern (191822) | more than 4 years ago | (#29204027)

You're making a fundamental mistake. You're assuming that the terminology applied by the vendor is meant to be descriptive. Its only purpose is to persuade people that they want to buy it.

Re:Encryption != Security (0)

Anonymous Coward | more than 4 years ago | (#29241381)

"Tampering" meaning, using the phone that you've paid for in the way that you want to. Hence the scepticism about "security" around in IT - it's fuck all to do with keeping you safe. It's about control.

Re:Encryption != Security (1)

Big Hairy Ian (1155547) | more than 4 years ago | (#29202811)

Wouldn't it make more security sense to make a proper random number generator chip than this as one of the main holes in PKI is lack of secure access to a proper random number generator and a reliance on pseudo random number generators.

Re:Encryption != Security (1)

mzs (595629) | more than 4 years ago | (#29204795)

They do, actually if I recall correctly in T2 they have one per core, where each consists of 3 cells each consisting of two n-well resistors (thermal noise essentially) connected to an amp which feeds into a VCO (voltage controlled oscillator) that gets sampled with regards to a different clock.

Re:Encryption != Security (1)

kheldan (1460303) | more than 4 years ago | (#29202907)

If it was a dedicated "security chip", responsible for ecryption/decryption, they'd never be able to export the thing, that's for sure.

Re:Encryption != Security (1)

vertinox (846076) | more than 4 years ago | (#29203777)

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.

Encryption takes the failure of a breach out of the responsibility of the computer and makes the greatest point of failure the human being.

That is much as we can hope for.

Re:Encryption != Security (1)

timeOday (582209) | more than 4 years ago | (#29205053)

That's silly, like claiming seatbelts and hardhats aren't safety devices since they don't guarantee safety. It goes without saying.

Bingo (3, Funny)

mseeger (40923) | more than 4 years ago | (#29202237)

"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."

Any experienced buzzword bingo player should have shouted out before reaching the end of the first sentence.

Difference from the T1/T2 on-chip cryptography? (3, Interesting)

BabyDave (575083) | more than 4 years ago | (#29202347)

As I understand it, the T1 and T2 chips both have on-chip crypto accelerators (one per core) already - what's the difference with the Rainbow Falls version?

Re:Difference from the T1/T2 on-chip cryptography? (1)

whitelabrat (469237) | more than 4 years ago | (#29202483)

That's right. I don't understand what is new here aside from marketing spin.

Re:Difference from the T1/T2 on-chip cryptography? (4, Funny)

johncadengo (940343) | more than 4 years ago | (#29204061)

As I understand it, the T1 and T2 chips both have on-chip crypto accelerators (one per core) already - what's the difference...?

Well, here it is as I understand. In T1, Arnold came back to terminate Sarah Connor and was unsuccessful. However in T2, Arnold was reprogrammed by future John Connor to defend his younger self. This cemented Arnold's historic status as both among humanity's greatest villains and greatest heroes of all time. And in California, because we love that stuff, these events ensured victory during his bid for power in the 2003 Governor Recall election.

Re:Difference from the T1/T2 on-chip cryptography? (1)

Nerdfest (867930) | more than 4 years ago | (#29204287)

The Rainbow Falls version has a front page SlashDot story pointing it out.

Re:Difference from the T1/T2 on-chip cryptography? (0)

Anonymous Coward | more than 4 years ago | (#29209615)

The presentation can be found here:

http://www.opensparc.net/publications/presentations/hotchips21-suns-3rd-generation-on-chip-ultrasparc-security-accelerator.html

You are correct that the 2 previous processors also had accelerators. This new one has a "fast-path" to the accelerator that allows user-land apps to interact directly with the accelerators; rather than having to go through the OS and Hypervisor. It is targeted at accelerating small packets.

Re:Difference from the T1/T2 on-chip cryptography? (4, Informative)

thogard (43403) | more than 4 years ago | (#29210933)

The T1 only has hardware to help with the initial key exchange. SSL traffic starts with an RSA key exchange using a a huge public/private key and then uses a block cypher like DES or SHA or RC4 to encrypt the data using the key that was exchanged via the RSA encryption. The T1 can't do block cyphers quickly and only has the first part speeded up. I found that my amd based X2100 would catch up to the T1 based T1000 after about 3000 bytes of an SSL stream and then quickly pass it. I've been told that the T1 was supposed to have block cypher hardware but maybe it was buggy and was disabled. Anyway sun should kill the T1 since its slow and expensive. Maybe thats their intent with their new T3120 but few details have been released.

Re:Difference from the T1/T2 on-chip cryptography? (0)

Anonymous Coward | more than 4 years ago | (#29214015)

The main difference is that the overhead to use the crypto accelerator is being reduced. The current version will only produce a speed advantage on bulk encryption of larger buffers, the newer chip will also accelerate smaller buffers. That extends its usefulness significantly.

Until someone cracks it (1)

plastick (1607981) | more than 4 years ago | (#29202395)

I wonder what will happen when "hackers crack security chip"? lol

Re:Until someone cracks it (1, Funny)

Anonymous Coward | more than 4 years ago | (#29206971)

I wonder what will happen when "hackers crack security chip"? lol

"World Awash In Magic Smoke"?

Unanswered Questions (1, Interesting)

segedunum (883035) | more than 4 years ago | (#29202487)

As there always is when you off-load some job on to a co-processor somewhere (even if it is on the same silicon) there are some unanswered questions:
  • 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.
  • 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.
  • 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? This history of co-processors for specific jobs has never been a very happy or long-lived one.

This doesn't look as if it's going to reduce encryption costs for most people as they say. 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.

Re:Unanswered Questions (2, Insightful)

JSBiff (87824) | more than 4 years ago | (#29202839)

"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 (0)

Anonymous Coward | more than 4 years ago | (#29203241)

"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.

Hrm, what about ssl encryption offload processors found in application switches and firewalls? This is just the same thing backported into a server.

Re:Unanswered Questions (0)

Anonymous Coward | more than 4 years ago | (#29209661)

It looks like that they way that separation ends is through integrated GPU/CPU hybrids... since the GPUs are becoming more and more general purpose, eventually there will be no point in using two different architectures at the same time. And as long as there is healthy competition between GPU providers we can't get stuck with a specific GPU architecture like we have with x86. The conclusion is that eventually all GPUs will run the x86 instruction set with some new GPU-specific extensions.

Re:Unanswered Questions (4, Insightful)

TheRaven64 (641858) | more than 4 years ago | (#29203359)

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:Unanswered Questions (1)

Ion Berkley (35404) | more than 4 years ago | (#29204519)

Why is this even on Slashdot? Its so un-news worthy, as pointed out by the previous commenter, this is the rule, not the exception these days. I had a paper at HotChips 10 years ago that presented an onchip crypto accelerator when it was actually a fresh idea. A more interesting discussion is perhaps whether payload encryption for applications such as VoIP belongs as an instruction set enhancement or as a stand alone co-proc. Many current chips that implement crypto co-proc's fail to utilize the true potential of the H/W offload due to setup cost and latency for such small packets. Another potential solution is to move it close to the network interface the same way that checksum offload has migrated with 1G and 10G NIC's

Re:Unanswered Questions (0)

segedunum (883035) | more than 4 years ago | (#29207249)

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.

Hmmmmm. So Sun are turning the Sparc platform into a specific platform for specific purposes with specific processing for specific tasks? Doesn't really sound like a computer to me so I don' know where you're going with that. It's a bit of a daft comparison. I was referring to Sparc's lack of performance when compared with the competitor that has ate its lunch over the years - x86.

But it's slower to replace standards than either, and encryption standards require years of peer review before they are approved.

Standards come, standards go, implementations change and get updated. That's why we have this thing called 'software' and why trying to do things in hardware that can be done in software on more powerful machines have generally fallen by the wayside. There are very few specific cases left.

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.

Bit of a stupid comeback really. On-chip floating point and vector processing isn't anywhere near comparable to putting full blown IPSec or similar encryption and decryption on the chip. The formers are common denominators of everything else. Graphics cards have proved to be the exception largely because graphics is still a growing field with ever expanding requirements that takes up significant resources. That won't always be the case but it will continue to be for some time. That certainly isn't the case with what Sun are doing, so again, you're using nonsensical comparisons.

Not sure what you mean by 'inherent lack of grunt'.

x86 systems have outperformed Sparc systems for over a decade now. That's largely why Sun's workstation market disappeared overnight.

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.

Oh please. Stop with that parellel workload and performance per watt shit. The vast majority of people don't have completely parellel tasks. They have tasks that double in size that they want completed in half the time. Those who have apparently parallel workloads don't because each thread of execution tends to depend on another completing at some point. That's the bottom line. Those workloads are very, very, very limited and it doesn't justify sustaining a whole hardware architecture. Performance per watt is a meaningless benchmark that can be measured in umpteen ways to cover up for Sparc's lack of performance when it comes to the opposition.

Sorry, but when Oracle gets in there I can only see them ditching what's left of Sun's in-house Sparc architecture systems unless they can make the architecture relevant performance-wise. This just isn't worthy of being news.

Re:Unanswered Questions (1)

owlstead (636356) | more than 4 years ago | (#29207317)

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.

Yes, of course, through their pkcs#11 provider, to be precise. Any application that can use PKCS#11 will be able to use this acceleration. Of course, *some* configuration will likely still have to take place. Java is actually pretty good already, you can simply add a security provider to the top of the list to accelerate any application. OpenSSL can work through PKCS#11 engine nowadays as well.

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.

Yeah, and don't forget that transistors are pretty cheap compared to going for the latest chip technology/speeds.

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.

Yup. Currently crypto instruction sets are pretty useful for specifically AES and hardware random number generation. SHA-1/256 acceleration is also useful of course, but SHA-3 is in the works - the NIST competition will run for at least another two years though. A Montgomery coprocessor (for DH, RSA and EC cryptography) may also be useful, but less than the AES and hash methods since signatures and key agreement are normally not performed as often, even though the time per encrypted byte is much higher.

I would advice CPU manufacturers to only implement a single round at a time though, so it is easier to add rounds and play with the algorithm before the round starts or after it ends. E.g. hash algorithms based on AES should be easier to be constructed this way. Same goes for the SHA-1 and 2 rounds. There is some talk about doubling the number of AES rounds already, and some hash methods in the NIST competition rely on AES rounds.

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.

Ha, pretty ironic. We'll just forget the FPU because it is completely integrated by now :)

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.

Yes, I think it might be one of the most undervalued processors.

Re:Unanswered Questions (1)

Gothmolly (148874) | more than 4 years ago | (#29203861)

I think Sun is gambling that the thready goodness of the new processors + the crypto coprocessors = something you want to buy.

Re:Unanswered Questions (1)

thanasakis (225405) | more than 4 years ago | (#29204321)

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.

If a piece of software uses OpenSSL, OpenSSL needs to be modified to use the hardware instead of doing computations the normal way (e.g. using instructions on the main processor). Some functions inside the library are being deferred to the hardware, for example the computation of a checksum.

Re:Unanswered Questions (0)

Anonymous Coward | more than 4 years ago | (#29206659)

> 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.

> It's easier to update software than it is to update silicon or chips.

Software drivers. See below.

> This history of co-processors for specific jobs has never been a very happy or long-lived one.

It'll be updated every year or two during upgrade cycles. The history of graphics coprocessors (GPUs) has been a happy, long-lived one...in regards to new silicon every 6 months.

scared about hidden DRM (-1, Offtopic)

MickyTheIdiot (1032226) | more than 4 years ago | (#29202637)

When someone talks about a "security chip" my immediate thought is they are talking about DRM.

Hopefully there is none trying to get snuck through the back door here (less of an issue since we are talking Sun, maybe).

Generalized accel, or specific algo's? (1)

JSBiff (87824) | more than 4 years ago | (#29202747)

Anyone know if this is a generalized solution, or an implementation in silicon of specific algorithms? I'm not terribly fond of the idea of specific algorithms being implemented in silicon, simply because, what happens if a weakness is found in the algorithm(s) being used, and they need to be changed? There was an article posted not too long ago to slashdot, about someone beginning to find weaknesses in AES. One of the problems with 'fixing' any flaws found in AES (one 'easy' solution being proffered in that particular case, IIRC, was to just increase the number of 'rounds' that the data is passed through the algorithm, or something like that) is that *any change at all* will be unsupported by specific implementations in hardware.

OTOH, if someone came up with a coprocessor which worked in conjunction with software/firmware (sort of a 'programmable' encryption co-processor) where you could update algorithms, or even use entirely new algorithms, that would be, I suspect, very useful.

Re:Generalized accel, or specific algo's? (1)

spinkham (56603) | more than 4 years ago | (#29203317)

It already exists in T2, with "Eight encryption engines, with each supporting DES, 3DES, AES, RC4, SHA1, SHA256, MD5, RSA-2048, ECC, CRC32" (From http://en.wikipedia.org/wiki/UltraSPARC_T2 [wikipedia.org])
Also, the T2 has hardware random number generator.
The T2 processor seems to be designed with web serving in mind, and especially makes an excellent SSL enabled web server.
I fail to see why this is newsworthy, as the T2 already does this quite well, and few people seem to care.

Re:Generalized accel, or specific algo's? (1)

sexconker (1179573) | more than 4 years ago | (#29203649)

If only there was some sort of array of logic gates, that was fully programmable.

Re:Generalized accel, or specific algo's? (1)

TheRaven64 (641858) | more than 4 years ago | (#29204941)

Or even one that was programmable in the field...

Making programmable hardware, or general-purpose hardware is easy. Making dedicated hardware that is fast and low power is easy. Making general-purpose hardware that is fast and low power is very difficult.

Bring out your dead (0)

Anonymous Coward | more than 4 years ago | (#29203383)

the SCO and SUN zombies are back. US economy is holding strong. No reason for investors to panic. film at 11

Encrypt in the Cloud (0)

Anonymous Coward | more than 4 years ago | (#29203537)

Why would you want a dedicated chip for this when cloud computing is in fashion? Offload your burdensome encryption work.

Re:Encrypt in the Cloud (2, Insightful)

pixr99 (560799) | more than 4 years ago | (#29204445)

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.

but is Oracle interested? (1)

peter303 (12292) | more than 4 years ago | (#29203735)

I was under the impression Oracle is not too interested in custom chips. The like Sun's servers and Sun software. I presume SPARC will be on the sellers block after the merger.

Re:but is Oracle interested? (2, Insightful)

TheRaven64 (641858) | more than 4 years ago | (#29204973)

Why? Oracle wants to sell appliances; just buy a box from them, plug it into your network and pay a lot for support. Given that the T2 running Solaris is the best platform for a large number of common Oracle configurations (anything with a large number of concurrent transactions), why do you think they'd want to sell off the CPU division?

Re:but is Oracle interested? (1)

raftpeople (844215) | more than 4 years ago | (#29206177)

One possible reason is that they didn't want to buy the hardware in the first place, they worked hard to make a deal that was software only, going to the extent of working out a combined deal where HP would get the hardware and Oracle the Software.

You can still provide the whole stack without being in the incredibly expensive and highly competitive CPU business.

What should occur, (0)

Icegryphon (715550) | more than 4 years ago | (#29204141)

Sun should build this chip and offer it as a Standard to other motherboard Developers.
Try to flood the Market with a Chip for Security and Give API's out to program for it,
Maybe even sponser a few opensource programs that are built use it.
The problem is Even thought the X86 platform does a lot of things well it doesn't do this as well as a chip specially designed for it.
As Encryption and Decryption become ever more important something like this could take off.(IMHO they always where)
But the key would be to make a standard and copyright it,
then flood the market with Cheap fabbed chips to server motherboard manufactures.

Maybe my Thinking is flawed, But I would like you heard your Thoughts.

Re:What should occur, (2, Informative)

Bill, Shooter of Bul (629286) | more than 4 years ago | (#29204825)

There are already several cryptographic accelerators available to slip into servers as add on cards. Plus, Via also makes an x86 compatible processor with similar security features. ( although you'd have to be brain dead to try and run one in a performance critical server).

Re:What should occur, (0)

Anonymous Coward | more than 4 years ago | (#29205435)

There already is an API for it, SCF (Solaris Cryptographic Framework). Simply link your encryption app against libpkcs11.so and it's good to go.
You can play with some of Sun's dedicated crypto boards such as the "Sun crypto-accelerator 1000 and 6000". The 6000 is FIPS 140-2 Level 3
compliant, allowing you to store your certs on the card and works in both Solaris/Opensolaris as well as Linux.
They probably won't be quite up to the performance you would achieve by having it on the CPU as the T2 already does but they are still damn fast.

Re:What should occur, (0)

Anonymous Coward | more than 4 years ago | (#29206625)

You mean, publish the specifications for the chip.

Kind of like what they did for the SPARC.

Kind of ironic that SPARC chips are more open compared to Intel chips, huh?

Bar Stewards (0)

Anonymous Coward | more than 4 years ago | (#29207373)

So now we need hardware to protect our on line existence

Looks at self

Looks at slashdot

And I wonder what is the point about me worrying about the human condition

It's not Sun, it's... (0)

Anonymous Coward | more than 4 years ago | (#29208183)

Don't you mean Oracle?

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...