Genesi today announced a new, PowerPC-based, modular MicroATX mainboard release that brings flexibility and efficient processing power to performance-intensive applications, including desktops, workstations, servers, and communications products. Read the rest of the press release.
Genesi selects IBM PPC for Performance-intensive Pegasos Release
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Just let me get Peg2 board and I’ll do something better ;-))
I am glad to see that Genesi is putting out new stuff. I like the concept of a non-mac power pc (not that I have anything against macs), but their previous offerings were kind of wimpy and hard to acquire. I am not very up to date on the names of IBM’s PowerPC chips. Am I correct in thinking that the 970 is the same as what Apple calls G5? The microATX version is supposed to have a 750Cxe. Would that correspond to another name in Apple lingo?
750Cxe = G3 (Maxes out @ 700Hhz).
for more information see:
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20…
Actually the G3 maxes out at 900 MHz, unless that’s Apple’s doing in overclocking those 900 MHz iBooks. I did hear that IBM had a 750 clocked at 1 GHz as well, this was a while back.
I liked this paragraph most: http://www.pegasosppc.com/guardian.php
To properly secure and protect your network, you need to run the Pegasos Guardian 24 hours a day, 7 days a week. The energy savings associated with the PegasosPPC motherboard is significant – consuming between one half and one tenth of the wattage of a Pentium processor.
I wanted a Pegasos until I tried to find documentation on the Marvell and VIA chips.
A search on Google shows a lot of people asking about documentation for various VIA chips, but no answers. Anybody know where the docs are?
The Guardian runs on a different processor platform and is not as susceptible to the common buffer overflows that are the main entry point for security breaches.
How is the PPC processor any less susceptible to buffer overflows than the x86 processor? Is that a non-sequitur, or is he confusing features of an OS with features of a processor, or is the PPC really somehow less susceptible to buffer overflows?
I wanted a Pegasos until I tried to find documentation on the Marvell and VIA chips.
A search on Google shows a lot of people asking about documentation for various VIA chips, but no answers. Anybody know where the docs are?
I don’t have a direct answer to your question, but here is what another hardware developer had to say about it: The biggest problem was that the VIA interrupt controller was missing interrupts on high loads, such as those generated by DMA transfers. The solution turned out to be a requirement to program an undocumented register in the VIA southbridge. VIA were particularly unhelpful in coming forward with documentation about what was obviously a well known and solved problem in the x86 world.
This may imply that the answer to your question is… they aren’t publicly available.
Thats a 750Fx, the G3’s max out @1.1Ghz (750Gx).
Genesi however uses the Cxe which uses a 256kb cache and maxes out at 700Mhz.
<quote>The Guardian runs on a different processor platform and is not as susceptible to the common buffer overflows that are the main entry point for security breaches.</quote>
How is the PPC processor any less susceptible to buffer overflows than the x86 processor? Is that a non-sequitur, or is he confusing features of an OS with features of a processor, or is the PPC really somehow less susceptible to buffer overflows?
There are two parts to this issue:
(1) Buffer overflow exploits rely upon the ability to overrun a data buffer into some executable code space, and
(2) the data that overflows has to be machine specific (machine code) in order for the target machine to do whatever the code writer wanted (unless the only purpose is to crash the machine).
First off (addressing the second issue first), since the PPC uses a machine code (instruction-set architecture) that’s worlds different from x86 machine code, there is very little chance (zero chance, for all practical purpose) that an x86 exploit would do anything but crash whatever program absorbed it, even if the PPC was running the “same” OS and software: Their just different beasts.
Secondly (addressing the first issue above), since the PPC is more like a true Harvard architecture (where code and data are in different memory spaces: Note the separate instruction and data caches), it is much easier to isolate changes to data from changes to code. In other words, due to the separate (effective) address spaces of a Harvard-style system, it’s much easier to make code immutable, while allowing for full access to the full data space. (There is, however, the caveat that the OS may mix instruction and data spaces, for whatever reason, in such a way as to invalidate this potential benefit. After all, it’s not always easy to implement linkers/loaders in an architecture where data and code are completely separate. Indeed, you have to have some way to get generated code, which is data, as far as the generating program is concerned, or stored programs, off disk, for instance, into the instruction address space so the processor can execute them, or you cannot have a general computer system.)
First off (addressing the second issue first), since the PPC uses a machine code (instruction-set architecture) that’s worlds different from x86 machine code, there is very little chance (zero chance, for all practical purpose) that an x86 exploit would do anything but crash whatever program absorbed it
Right. That’s “obvious”. (Not to most people, I agree; but I understood that from the get-go. 🙂
There is, however, the caveat that the OS may mix instruction and data spaces…
This is what bugs me about his claim.
But the rest of your post answered my question, thanks a lot!
One of these should make a great Linux box.
First, thanks to David. Good answer!
As we see it a good portion of buffer overflow exploits are targeted toward the x86 processor instruction set. There still are ones for other processor platforms, and PowerPC is one of them, as is SPARC. However, the best way to examine buffer overflow exploits and do so with minimal chance of harm is to provide inspection from a non-x86 platform. Using PowerPC does not completely mitigate the risk of a buffer overflow. Rather, it provides a platform on which a good portion of exploit code cannot run, since the amount of crackers targeting PowerPC platforms is much smaller than the set trying x86. Thanks for allowing us to clarify that.
As a nearly any system administrator will tell you, there is no magic bullet for security solutions. You have to have an interlocking platform of policy, procedures, and enforcement (of policy and procedures). This has spurred the use of Open Source in security over the years in systems, since it allows a way to audit the systems via the code they run. We realize there are many system administrators that are that paranoid. Providing the customer with the source code to the system does two things:
1. This allows the customer to audit the code.
2. It also allows the customer to build on the code.
However, there is also a learning curve for these products that is very high, and even experienced system administrators can get easily confused with these products. This product provides a way of reducing the time needed to set up and configure a firewall for a network that provides more than just the basic features. This product also provides for detection and filtering of malicious traffic, and can be custom-configured for the network.
The use of Open Source tools also provides multiple integration paths through both the Open Source and commercial channels, meaning that with customization, it should be possible to include this as part of a total security system/posture.
The choice of OpenBSD also allows for a platform that has been specifically audited for buffer overflows and race conditions, out in the open. Code from this product and its offshoot projects such as OpenSSH are used in multiple commercial products. Mitigation cannot take place in one place, it has to occur at multiple levels, and we consider this to be one level.
There is no way to eliminate buffer overflows. However, there are steps as part of a total security plan that can be taken to include this as part of a security process. This is only one part of the total security solution and posture that a company can adopt. Firewalls and IDSs are only one part of your total protection measure. PowerPC is not just a one-step band aid. It is a starting point. Customers need a total security posture, and this is one component of it, providing border-level or internal protection as a component of a security system, not the system itself.
Hope that makes you comfortable with our position on this product.
Sincerely,
R&B
[email protected]
I read recently on Jerry Pournelle’s Website that Microsoft was going to recompile Windows XP with Bounds Checking turned on in the compiler in order to stop a lot of the Buffer Overflow problem.
It would end up being a HUGE Service Pack, but would add a lot to the stability and security of the system.
I’m not a programmer at all.
Just passing this on.
It was on his site in the last month, so it should be easy to find. It might also be in one of his BYTE.COM Columns.