Domain: iseriesnetwork.com
Stories and comments across the archive that link to iseriesnetwork.com.
Comments · 7
-
IBM maintains a nice "legends" page
about their iSeries and such
http://www-1.ibm.com/servers/eserver/iseries/legen ds/index_flat.html
It also includes the "server" lost behind the wall. The reenactments are cute and somewhat based on "true" stories.
Another set of stories is at...
http://www.iseriesnetwork.com/nodeuk/ukarchive/ind ex.cfm?fuseaction=viewarticle&CO_ContentID=13885 -
Cold Fusion is rather insecure...Cold fusion is rather prone to SQL-injection problems:
-
iSeriesNetwork just got sql-raped!Protecting Against SQL Injection Attacks
It's hilarous!
-
Information search revealsArticle published in 2000 which says Windows will be the dominate software model displacing UNIX on the server, might be nice to ask him about this. Also since meta group coordinates the opinions expressed by their 2000 consultants worldwide, eg from their corporate info, this is meta groups opinion you might want to ask what meta group's current position is on Linux in both the server and desktop market.
The only bright spot for UNIX is the fact that Oracle scales better on UNIX than on Windows.
In another article he talks about how with the introduction of intels ia64 chip UNIX will be regulated to the back room running a Database and will basically die out.
In article "Wintel Vendors: Data Center Addition?" Sorry no public link.
He opens saying that the impact of Linux on the data center is negligable compared to Windows which growth is expanding faster than anything else.
Looking through this information it also strikes me that he has always help product marketing positions, but has no listed experience actually having implemented and designed any of this.
He is also one of metagroups leading open source knowledgeable people without ever having worked with Linux. link
In this article
he states "anything but Linux on Intel is niche." and seems to poo-poo any thought of running linux on non-intel equipment... Which doesn't speak well for his Linux experience... He claims that they only look at what his clients are doing, so it seems that he won't know about it unless they are doing it and his job is to advise them on what to do... Make your own conclusions...
In this article dated April 20th, 2004 so it should reflect his current position, he seems to be promoting Linux. Definately worth a read through.
And this article back in dec 09th 2002 he states he see's in 5 years windows at the low end and linux at the high end of computing.
Meta Group's position
2001 Linux not on their roadmap
2002 Linux is immature and should not be used in mission critical applications
2003 - current not sure
Overall it looks like he isn't a techie, just a manager that overlooks what consultants in the field are do and provides a "face" for the UNIX department. Doesn't look like he's a Microsoft shrill especially considering the last two articles I left on him.
Hopefully this helps, going to sleep.
-
Re:Power4 is not PowerPC except when it is :)
Found the article www.iseriesnetwork.com. Verry good history of the IBM architecure and some info on the upcomming POWER5 and POWER6
-
Re:Uh already 64bits, it's the 1.8Ghz that is new
The PowerPC architecture was an offshoot of the Power architecture used in IBM's RS/6000s. There's actually a pretty interesting history to all this mess, but the upshot is that the 64-bit "PowerPC" architecture has been in use since 1995 in AS/400s. Actual PowerPC has been 32-bit all along, and will be until the 1.8GHz chip comes out next year.
Here's a reference by one of the guys involved in the design of the chip (Frank Soltis, original architect of the S/38, AS/400, and iSeries): When is PowerPC not PowerPC? -
The real problem
The worst problem regarding security is probably the fact, that today's mainstream processors mix up code, data and adresses in memory without being able to distinguish between these categories.
You can put anything (even some characters of input from the keyboard) into memory and let the computer use it as a memory address - and this is really a very, very bad architecture.
If an attacker could only modify data by exploiting buffer overflows instead of being able to put additional code on your machine and to execute it, his or her possibilities would be much more limited.
Most secure operating systems can't prevent a security breech within an application, but are still able to prevent access to the OS itself, to other applications or to sensitive data. This is done by strictly following the 'principle of least privilege', which mainly means that you do not run any process with all-powerful root privileges.
(Take a look at Argus' homepage for more information about secure Unix kernels with authorizations/privileges instead of 'root')
IBM invented a technology which would be suitable for protecting the system from unintentionally modified addresses, almost 20 years ago (in the System/38).
We definately need better processors and better operating systems.
A short summary of methods to prevent from buffer overflow exploitation:
* If a process CALLs a subroutine, the return addresses shall become pushed onto the stack and marked as a 'valid address' in some kind of shadow memory (if you have 64bit long addresses, you need 128MB additional memory as the shadow RAM for each 1024MB RAM).
* If some piece of data is MOVed to memory, then the memory region shall become marked as 'non-valid address' in shadow memory.
* If a processor tries to fetch an address from a memory region which is not marked as 'valid address' then the processor shall raise an exception (interrupt) to inform the operating system about the invalid pointer.
* Shadow memory shall only be accessible from the highest privilege level (that is, from kernel mode)
* User mode processes shall not be able to use OS APIs in order to mark modified addresses as 'valid address' unless the user process has the privilege to use the API.
* There should be a privilege which causes the OS to ignore invalid pointers and resume execution of a user process, in order to ensure that even very old programs (which use pointer manipulation without correct casting, etc.) can be used.
Unfortunately, there is almost no information on the net about hardware pointer protection, so you will possibly need to look into Frank Soltis' book "Inside the AS/400" to get very detailed information.
Inside the AS/400, Frank Soltis