Considering there is 128-way SMP version of Windows (running on NT) available
I might be wrong, but AFAIR, the largest SMP configuration supported by NT is 32 CPUs (or, probably, 16 Hyperthreading-CPUs) because of a constraint compiled into the kernel (Windows "Datacenter Server" Edition).
Anyway, even if you could run NT on some 128 CPUs, it would not scale well. If you actually knew a little about the NT implementation and not just the "microsoft propaganda", you'd possibly figure out, that a lot of (theoretically independent) code portions in the NT kernel synchronize on only one mutex-like synchronization lock (CRITICAL_SECTION) that is shared between these code portions
Example: If you've got 50 independent data structures, you could use 50 mutex locks (one for each data structure), to protect it form becoming corrupted due to simultaneous modification by multiple threads. The NT design in this example would be to use only 5 CRITICAL_SECTION locks for the 50 independent data structures (one for every 10 data structures), so one thread modifying a data structure will potentially lock out 9 other threads who could be modifying 9 other data structures.
The lack of fine grained synchronization on NT makes it scale pretty bad, especially compared to Solaris (which scales so well probably mainly because of very fine grained and sophisticated synchronization, for example by using RW-locks instead of mutex-like CRITICAL_SECTIONs in situations where this is possible).
If you have to deal with classified information, you may want to use an information labeling operating system (one that supports mandatory access control) such as Trusted Solaris.
Any OS that has been evaluated against the TCSEC B1 specification should be suitable.
However, I don't know much about special hardware... AFAIK there isn't a lot of certified hardware from the mainstream PC vendors (Dell, HP,...); some companies more specialized in IT security (Getronics for example) offer combinations of certified hardware and software (up to TCSEC A1 IIRC).
We just updated an Office 97 (German) to Office 2000 (German); now, when the user opens some of her old documents, Excel suddenly becomes a mixture of a german-and-english program, with some english menus and some german buttons (or vice-versa) here and there, and some of the functions do not even work properly. If Excel is used to create a new document, everything is o.k., and all the menus and buttons are german.
I was not able to find an option like "program language" to fix the problem.
It just seems to be a software error - I am even almost sure, that the reason for errors like this one is nothing else than really *bad* software design.
In my job I have to fix approx. 3 MS Office installations per day (we have got ~ 6,000 clients with MS Office installed), so I even avoid using MS Office with simple documents (no macros, no "programming"...), because of its unreliability; there is almost always something that does not work anymore, when I use an Excel 2000 file with Excel 2002, or after an Update of MS Office.
Do we really want to use such unreliable software as the foundation of our own projects, maybe even for processing mission critical data?
What about software design rules like: "5 Rule of Simplicity: Design for simplicity; add complexity only where you must." "6 Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do."
Do we really need to use a 187 Megabyte piece of complex, untransparent code with some 1,000 bugs when 150 lines of code can do the job?
So, *PLEASE* do not script MS Office; let real programmers write real programs.
I am still running the beta-69 release (on x86), which required some "creativity" to install, because the install procedure was not completely finished yet. But even the beta runs fine now, and the new privilege model (instead of just root/world privileges) solved a lot of problems for me.
You can, because the system uses different types of pointers - for example, to address a character array, a combination of space offset pointers and a system object pointer is used; the machine just checks, whether your space offset pointer still points inside the space allocated to your (protected) system object pointer. However, you cannot use a space offset pointer as an argument to a subroutine call instruction.
There is a much more effective technology around since about 1988. IBM's AS/400 (now called "iSeries 400" or "eServer i5") has a feature called "Pointer in memory protection".
Every time when the processor writes an address into memory (for example, return addresses stored in stack memory by subroutine calls) the memory location is marked as containing a valid address by using a "shadowed" flag, a 65th bit (one bit of ECC memory is used, so the machine does not need special memory modules, just standard ECC memory modules). If that memory location is overwritten with data, the CPU automatically clears the "shadowed" flag. If the CPU tries to use a pointer as a memory address, that was overwritten with data before, it automatically generates an interrupt.
This feature was originally not designed to be a buffer overflow protection, but it was neccessary, because the AS/400 uses a so-called "single level storage", where all applications use the same address space. Therefore, the machine needed some method to prevent applications from writing to arbitrary locations in memory, and that's why pointer-in-memory-protection was invented.
Actually, the memory is also segmented, one segment for every "object" created by a program. Most buffer overflows can not even overwrite an address, because a character array will have its own object boundary. For example, the following code will typically not generate a buffer overflow on an AS/400:
int main(void) {
char space_a[20];
char space_b[20];
int i;
for (i = 0; i < 100; i++)
{
space_a[i] = 'A';
}
for (i = 0; i < 100; i++)
{
space_b[i] = 'B';
} }
Just try it out, it should not even crash. I tried a lot of things like these on an AS/400 Mod. 170 running V5R2 using IBM ILE C compiler.
I think, pointer protection using shadow flags is the right way to prevent execution of code inserted by exploiting buffer overflows, because all other protection methods can't prevent return-into-libc exploits, but the pointer-in-memory-protection can, so IMHO it is the only *real* protection.
Further reading: "The inside story of the IBM iSeries" by Frank Soltis (a book about the architecture of the iSeries and the POWER processors)
In my opinion, it's not an administrator's job to frequently find his/her way to actively prevent problems, that are actually caused by poor software design. It's the job of the software designers and/or programmers, to provide administrators and users with robust and reliable software. A program, that by design frequently causes a problem that makes it unusable/unavailable to users, is poorly designed.
"Hey, these Cray computers are really expensive; but I figured out, that we could just use personal computers instead, if we emulate the load balancing hardware, so let's just put together some 50,000 x-boxes. Ooooh! These x-boxes are even cheaper! We just have to emulate the PC software in order to be able to emulate the load balancing hardware on the X-box. LOOK AT THIS!!! We can even use Excel instead of our expensive mathematics software, we just need to put in some Visual Basic Script, connect it with some DOS-based C++-Code to the NT-based Java-Code, and send the results to the Linux-based Emulator, and everything should work!! This is even CHEAPER!!!11!!!111"
2 Weeks later
"Uhmm.. now what's that? It can't be zero!? Shouldn't it be something like 68 Billions and 45 Millions or something?.. oh no.. can I borrow your screwdriver? We should also exchange node #43091, I think, something's wrong with the memory.."
First, they exchange all the professional, mature and robust parts with the cheapest consumer-class devices available on the market, and then they start wondering and complaining, why nothing works reliably anymore...
IBM z/OS V1.x
one vulnerabilty (in Sendmail, which was ported to z/OS)
By the way, most (if not all) parts of z/OS were written in PL/1.
IBM OS/400 - V4.x, V5.x
zero vulnerabilities
(Note, that OS/400's kernel ("SLIC"), written in C++, is absolutely closed code (afaik you can't even access its machine code on the iSeries 400's DASD), so nobody outside IBM knows, what kind of bugs might be in that kernel; anyway, because of its single-level storage architecture, this system has hardware pointer-in-memory protection, which, as a side-effect, prevents many of the most dangerous kinds of exploits, for example overwriting of return-addresses, overwriting of function pointers and such; so it's impossible to "smash the stack" on this machine)
Conclusion:
===========
To err is human; as long as people use Assembler, C or similar programming languages, they will probably cause buffer overflows and similar bugs; for this reason, we should take advantage of more intelligent hardware architecture, including features like tagged pointers and special CPU instructions for modifying addresses (so you still can change a function pointer, but only if you use the correct instruction; overwriting it using instructions for copying data areas (MOV on intel) would cause the pointer protection hardware to invalidate the pointer). Better hardware is a good foundation for better software. "Protected mode" (memory protection, preemptive multitasking,...) brought us stable operating systems; some new hardware could get us stable and secure operating systems.
By secure I DON'T mean hardware-addons like TCPA. TCPA is inadequate for a free-programmable computer architecture.
Use a suitable programming language to implement applications; you don't need to mess around with direct memory access, pointers and such, if you're programming software for accounting or a spread sheet application.
Many commercial applications for z/OS and OS/400 are written in COBOL, PL/1, etc. rather than in C, and they do not seem to have nearly as many critical bugs as most C programs; OpenVMS people will tell you the same story, I don't know what programming language they used to write most of their applications, but I know it wasn't C.
If you can't get an open source Ada, Cobol, PL/1,... compiler, at least use C++ (use std::string).
Don't forget Java; java programs might not be as fast as compiled code, but especially non-GUI applications are still pretty fast, and Java is a well-designed language.
Unfortunately, there are no results for trusted operating systems such as Trusted Solaris; it would be interesting, whether the same bugs that are critical on standard operating systems could cause system access or any similarly critical escalation of privileges on trusted operating systems (my guess is, commonly not; these systems have extremely strong security implemented in kernel code). By the way, Solaris 10 will include many key security features that were only available in Trusted Solaris before (including privilege sets and compartment-like process separation).
Book hint: "The Inside Story of the IBM iSeries" by Frank Soltis, the system architect of the iSeries 400 (aka AS/400) and OS/400; especially interesting because of the fact, that this system's design is very different from common hard- and software architecture;
Most of UNIX's concepts are technically more consistent and logical than those of Windows.
For example, because of the Windows registry you can't simply copy a program to a CD, then delete your harddisk, reinstall another version of Windows, and copy the program back to harddisk, because the program won't work anymore. But you can do that on Unix. The concept of the Windows registry mixes all parts of the operating system, user applications, configuration files, etc. into one big datastructure. Windows even lacks any intelligent way of backing up and restoring a program and all its registry settings alltogether. That's one of the reasons why I still think, that Windows is a poorly designed operating system. On UNIX, a program is simply some files in the VFS tree. If the files are there, then you can run the program. Backup/restore is as simple as "tar -cvf..." and "tar -xvf...". Plus you can build a program on one machine and then simply copy it to another one.
Another example is the concept of foreground and background processes on both platforms. Windows cannot run every process in background; processes need to implement special interfaces to run them at system startup, and you can only start and stop them by using the service control manager, you can't kill those processes.
On Unix, you can start any program at system startup as a background process. If that process won't stop anymore, you can kill it just like any other process.
That's what makes programming and using computers simple and logical.
Windows is probably more consistent in what the user sees (the look and feel of GUI widgets in different applications), because there is only ONE GUI subsystem, which is integrated into the operating system kernel.
However, comparing Windows with UNIX at the GUI level is somehow like comparing a banana with a tree. X11 is a (privileged) user space process running on UNIX, it's not an integral part of the operating system. Actually, the fact that X11 is simply just another user space process is a concept that adds some flexibility and also robustness to UNIX. If something in the GUI fails (the window manager, the desktop manager, the graphics device driver), you can simply kill and restart the entire GUI subsystem without rebooting; you can even install another graphics device driver without rebooting the OS. Actually, sometimes when a window manager fails, I just kill the window manager and then reinsert it between the X client applications and the X server - even that works fine. Anyway, X11 is not UNIX, it's just an application running on UNIX.
That makes 4 'virtual' CPUs. Anyway, as most PC users are running NT (or one of its successors), and as locking is anything but fine-grained on NT, while one thread running on one CPU will call some NT kernel function which locks a CRITICAL_SECTION, three other threads running on the remaining three CPUs, who call some other kernel function, will wait for the same CRITICAL_SECTION; effectively, only one CPU gets any real work done.
That's why some other OSs may perform similar on uniprocessor hardware, but may substantially outperform NT on multiprocessor hardware. For example, if you take a look at the SunOS kernel, you'll find much more efficient locking techniques (faster mutexes, lots of rw-locks, more fine-grained structures == better parallellization).
Multiprocessor hardware performs well with technologically sophisticated software only; I mean: it doesn't make sense to increase the number of processors if you don't use all of them simultaneously.
> Concerns about stability? Security? Dislike of Microsoft's business practices?
All of these, plus:
* i don't like the Win32 API; APIs like CreateProcess, CreateThread, FindFirstDirectory (or similar), FindNextDirectory - all of those are not very elegant designs;
* the registry is a misconception;
* windows will send any signal from any GUI process to any other GUI process, ignoring different security context; that's a security design error;
* it does not run efficiently on multiprocessor hardware;
* programs need to be especially designed and installed, if you want to run them as background processes (program must be a "Service"); what a stupid idea %-/ - and if they fail, you can not even kill them using a task manager;
In my opinion, the NT kernel is a bad design; i think, that's where most of the bugs come from (not because of bad implementation, but because of bad design).
This is an Intel Platform Edition machine (Solaris x86).. there is definately something wrong with those color computations, and/usr/lib/signal.h defines DS, which scribus/seiten.h tries to use as a variable name for some kind of a Qt widget...
Now I finally got 1.1.6 installed on my Solaris box.
For all Solaris users:
Regarding the error on line 139 in scribus/seiten.h: (parse error before numeric constant) The code on line 139 is: QCheckBox* DS;
On Solaris, and possibly on many other Unix System V Implementations, DS is already defined if something includes signal.h; to fix this error, place the following line into seiten.h (right after the #include statements): #undef DS
I compiled Scribus on an Intel Platform Edition machine, which is a little-endian architecture. After installing Scribus, i got the following error: xlib_rgb_init: compiled for big endian, but this is a little endian machine.
I tried a lot of modifications in gdk-pixbuf*.[ch] and in config.h to make it work, but it always starts up with a white page that turns red after about 1/4 second. If I choose red as background color for the page, the page turns darkgreen. Combinations of red and blue work, combinations of blue and green do also work.
I don't know what's wrong with the colors, but to me it seems like the developers of Scribus really messed up a lot of things regarding big-endian/little-endian dependent computations (I wonder where you need such computations in your code, when you just want to view an empty page.)
So, it theoretically works. Practically it doesn't, because the color computations are broken...
Either this is security-by-obscurity, which means, that I'll be able to listen to the same song as many times as I want to (for example, by simply restoring a 'safety copy' of the file, or maybe by circumventing application security (using a debugger)), or I must not be able to copy the file (or to open this file with any program other than Microsoft's WMA player), which effectively makes my computer unusable, because I can't use my own (or 3rd Party Software) on it anymore (then maybe it's still a Microsoft-CD-Player-with-integrated-Microsoft-Type writer, but not a computer).
Just imagine UNIX without the possibility of using pipelines, because only ONE specific program works with a specific file; you must not even be allowed to read from/dev/fd0 or something, because that would allow you to copy the file's content. You must not be allowed to debug certain applications on your computer.
Now imagine a cracker, who can get a DRM certificate for his newest virus (don't say, it's impossible.. . What about DRM-protected viruses? There will be only a very small group of people who would then be able to isolate the virus.
I think, we could find a lot of other potential 'accidents' with DRM technology.
DRM technology can't work realiably on open computing platforms, it will always be either totally insecure ('obscure' instead of 'secure'), or it will at least be potentially dangerous. Don't use it.
In my opinion, there is no substantial difference in code quality between open source software and proprietary software.
I have seen a lot of very buggy commercial software (including nVidia drivers, IBM's LANManager Services for OS/2, lots of Microsoft's services and utilities in Windows 2000 (for example, "TCP/IP Helper Service") and Netscape 4.7).
On the other hand, I have also seen very bad code quality in open source products - for example, GTK+ (actually, the really bad thing about GTK+ is primarily its install scripts, makefiles and such). Compiling and installing GTK+ on anything else than on a GNU/Linux-machine is some kind of an adventure, while its commercial counterpart, Qt from trolltech, can be compiled quite easily.
- I set the PKGCONFIG env variable before running 'configure'. It worked quite well until line 27.000 (or so) in 'configure', where the variable's content was suddenly gone (BTW, I really dislike debugging 28.000+ line shellscripts). I tried to 'configure' with bourne shell and with korn shell 93.
- It assumes, you have Perl installed (if it's not in your PATH, 'configure' creates funny things like "#! -w" instead of "#!/path/to/perl -w"). The error message produced due to this bug was something like '/usr/bin/env: no such file or directory' - because the perl script was directly started using/usr/bin/env. Kind of confusing %-)
- 'configure' forgot to add '-fPIC' to CFLAGS, for this reason all shared libraries where broken. I had to add this option manually.
- Nothing works with 'make'. I had to install 'gmake' (GNU make) instead.
- The actual source code of the core libraries finally compiled, after I had upgraded to gcc 3.3.2. The source code of the 'demo' programs was totally broken, and gcc refused to compile it - once more I had to change the makefiles manually.
-----
One or two weeks later I compiled trolltech's Qt library on the same computer. It was as simple as './configure --platform=platformname && make && make install'.
Why do I need to debug 28.000+ lines of shellscript-code and a lot of makefiles, why do I need to install gmake, pkgconfig (by the way, pkgconfig and most other things in GTK+ don't work well if you don't install everything to/usr/local, which is the default location) and Perl 5, just to compile some C/C++-Code?
Qt does mainly the same as GTK+, but it simply compiles, using only shellscripts, 'make' and a C/C++ compiler.
Another example regarding code maturity (rather maturity than quality, notice the difference:-) is Sun JVM vs. GCJ's libjava. I compiled a very complex multithreaded application using GCJ; it worked fine on uniprocessor machines, but it randomly deadlocked on my multiprocessor server. Finally I found out, that libjava is broken on SMP machines. That doesn't mean, that libjava's code quality is bad; but it still means, that some other Java-Libraries (those of some virtual machines) are more mature, and possibly better tested.
-----
Some fundamental things about Software: - The more people read the code, the more people can potentially find and fix bugs (good about open source). - If a lot of people are allowed to write the code, somebody has to coordinate the work of all these people. Lots of different versions of the same module, written and/or modified by lots of different people need to be combined or coordinated otherwise (bad about most open source projects, because hardly somebody knows, how trustworthy anyone of the developers is; good abous some closed source projects (e.g. Trusted SunOS kernel, IBM SLIC kernel and other trusted code), because only a small group of really good programmers is allowed to write or modify code).
Conclusion: It's good to have only a small group of 'trusted' developers, who write or modify the code, and then to let everyone else read and verify the code.
I've been using Solaris x86 several years now, and it is still my favorite UNIX OS on the x86. As far as I can tell from my experience, its kernel is more sophisticated than the Linux kernel (kernel level audit trail, ACLs, fine grained locking,...), especially regarding smooth multitasking/-threading under very high system load.
There is also a very interesting version of Solaris, called Trusted Solaris, with very strong security.
And remember, all versions of Solaris x86 run very fine on SMP machines; it still seems to be more scaleable (or more efficient on big machines) than Linux and/or BSD.
Funny, I had pretty much the same idea... I use my own C library (which is called "secureStrings") for my programs for some time now (about one year), because it has always been my opinion, that things like strcpy() and strcat should become forbidden;-). SecureStrings works on Unix, VMS and OS/400; i didn't try, but it probably also works on NT...
C or C++ is probably great, for writing very special code, such as kernel modules to support new hardware, or scientific software and such. However, I think there should be a more secure programming language than C for commercial and for networking software.
Implementing things like a webserver, a data warehouse, accounting software, etc. in C/C++ can be extremly dangerous, and experience shows, that most programmers just can't do it the right way with C/C++.
On Mainframes and AS/400s most commercial applications are written in COBOL, and this is probably one of many reasons, why these systems usually don't get hacked.
However, COBOL is somehow unhandy (unconventional syntax)
On Unix you can hardly get something else than a C/C++- or a Java-compiler; there should be an Ada- or a Pascal-Compiler available for every Unix derivate.
Fine grained privilege controls instead of root/world
Trusted path login (up to TCSEC B3)
Trusted computing base
where C2 or B1 might be required.
At least C2 security should be the standard on every server which is used for commercial applications (storing private data, processing business transactions,...).
Servers which store credit card numbers or something like that may not need to take sensivity labels into consideration, but they should at least be split into separate compartments for each application.
Slashdot Mirror
Considering there is 128-way SMP version of Windows (running on NT) available
I might be wrong, but AFAIR, the largest SMP configuration supported by NT is 32 CPUs (or, probably, 16 Hyperthreading-CPUs) because of a constraint compiled into the kernel (Windows "Datacenter Server" Edition).
Anyway, even if you could run NT on some 128 CPUs, it would not scale well. If you actually knew a little about the NT implementation and not just the "microsoft propaganda", you'd possibly figure out, that a lot of (theoretically independent) code portions in the NT kernel synchronize on only one mutex-like synchronization lock (CRITICAL_SECTION) that is shared between these code portions
Example:
If you've got 50 independent data structures, you could use 50 mutex locks (one for each data structure), to protect it form becoming corrupted due to simultaneous modification by multiple threads. The NT design in this example would be to use only 5 CRITICAL_SECTION locks for the 50 independent data structures (one for every 10 data structures), so one thread modifying a data structure will potentially lock out 9 other threads who could be modifying 9 other data structures.
The lack of fine grained synchronization on NT makes it scale pretty bad, especially compared to Solaris (which scales so well probably mainly because of very fine grained and sophisticated synchronization, for example by using RW-locks instead of mutex-like CRITICAL_SECTIONs in situations where this is possible).
If you have to deal with classified information, you may want to use an information labeling operating system (one that supports mandatory access control) such as Trusted Solaris.
Any OS that has been evaluated against the TCSEC B1 specification should be suitable.
However, I don't know much about special hardware... AFAIK there isn't a lot of certified hardware from the mainstream PC vendors (Dell, HP,...); some companies more specialized in IT security (Getronics for example) offer combinations of certified hardware and software (up to TCSEC A1 IIRC).
We just updated an Office 97 (German) to Office 2000 (German); now, when the user opens some of her old documents, Excel suddenly becomes a mixture of a german-and-english program, with some english menus and some german buttons (or vice-versa) here and there, and some of the functions do not even work properly. If Excel is used to create a new document, everything is o.k., and all the menus and buttons are german.
I was not able to find an option like "program language" to fix the problem.
It just seems to be a software error - I am even almost sure, that the reason for errors like this one is nothing else than really *bad* software design.
In my job I have to fix approx. 3 MS Office installations per day (we have got ~ 6,000 clients with MS Office installed), so I even avoid using MS Office with simple documents (no macros, no "programming"...), because of its unreliability; there is almost always something that does not work anymore, when I use an Excel 2000 file with Excel 2002, or after an Update of MS Office.
Do we really want to use such unreliable software as the foundation of our own projects, maybe even for processing mission critical data?
What about software design rules like:
"5 Rule of Simplicity:
Design for simplicity; add complexity only where you must."
"6 Rule of Parsimony:
Write a big program only when it is clear by demonstration that nothing else will do."
Do we really need to use a 187 Megabyte piece of complex, untransparent code with some 1,000 bugs when 150 lines of code can do the job?
So, *PLEASE* do not script MS Office; let real programmers write real programs.
I am still running the beta-69 release (on x86), which required some "creativity" to install, because the install procedure was not completely finished yet. But even the beta runs fine now, and the new privilege model (instead of just root/world privileges) solved a lot of problems for me.
Anyway, considering average quality of software on the PC, 'PC-Crash' is a really cool name...
You can, because the system uses different types of pointers - for example, to address a character array, a combination of space offset pointers and a system object pointer is used; the machine just checks, whether your space offset pointer still points inside the space allocated to your (protected) system object pointer. However, you cannot use a space offset pointer as an argument to a subroutine call instruction.
There is a much more effective technology around since about 1988. IBM's AS/400 (now called "iSeries 400" or "eServer i5") has a feature called "Pointer in memory protection".
Every time when the processor writes an address into memory (for example, return addresses stored in stack memory by subroutine calls) the memory location is marked as containing a valid address by using a "shadowed" flag, a 65th bit (one bit of ECC memory is used, so the machine does not need special memory modules, just standard ECC memory modules). If that memory location is overwritten with data, the CPU automatically clears the "shadowed" flag. If the CPU tries to use a pointer as a memory address, that was overwritten with data before, it automatically generates an interrupt.
This feature was originally not designed to be a buffer overflow protection, but it was neccessary, because the AS/400 uses a so-called "single level storage", where all applications use the same address space. Therefore, the machine needed some method to prevent applications from writing to arbitrary locations in memory, and that's why pointer-in-memory-protection was invented.
Actually, the memory is also segmented, one segment for every "object" created by a program. Most buffer overflows can not even overwrite an address, because a character array will have its own object boundary.
For example, the following code will typically not generate a buffer overflow on an AS/400:
int main(void)
{
char space_a[20];
char space_b[20];
int i;
for (i = 0; i < 100; i++)
{
space_a[i] = 'A';
}
for (i = 0; i < 100; i++)
{
space_b[i] = 'B';
}
}
Just try it out, it should not even crash.
I tried a lot of things like these on an AS/400 Mod. 170 running V5R2 using IBM ILE C compiler.
I think, pointer protection using shadow flags is the right way to prevent execution of code inserted by exploiting buffer overflows, because all other protection methods can't prevent return-into-libc exploits, but the pointer-in-memory-protection can, so IMHO it is the only *real* protection.
Further reading: "The inside story of the IBM iSeries" by Frank Soltis (a book about the architecture of the iSeries and the POWER processors)
In my opinion, it's not an administrator's job to frequently find his/her way to actively prevent problems, that are actually caused by poor software design. It's the job of the software designers and/or programmers, to provide administrators and users with robust and reliable software.
A program, that by design frequently causes a problem that makes it unusable/unavailable to users, is poorly designed.
"Hey, these Cray computers are really expensive; but I figured out, that we could just use personal computers instead, if we emulate the load balancing hardware, so let's just put together some 50,000 x-boxes. Ooooh! These x-boxes are even cheaper! We just have to emulate the PC software in order to be able to emulate the load balancing hardware on the X-box. LOOK AT THIS!!! We can even use Excel instead of our expensive mathematics software, we just need to put in some Visual Basic Script, connect it with some DOS-based C++-Code to the NT-based Java-Code, and send the results to the Linux-based Emulator, and everything should work!! This is even CHEAPER!!!11!!!111"
.. oh no .. can I borrow your screwdriver? We should also exchange node #43091, I think, something's wrong with the memory.."
2 Weeks later
"Uhmm.. now what's that? It can't be zero!? Shouldn't it be something like 68 Billions and 45 Millions or something?
First, they exchange all the professional, mature and robust parts with the cheapest consumer-class devices available on the market, and then they start wondering and complaining, why nothing works reliably anymore...
"...I know that bug is gone, didn't you notice that we upgraded our systems at 10:35 a.m.?" ;-)
Look at these:
...) brought us stable operating systems; some new hardware could get us stable and secure operating systems.
By secure I DON'T mean hardware-addons like TCPA. TCPA is inadequate for a free-programmable computer architecture.
IBM z/OS V1.x
one vulnerabilty (in Sendmail, which was ported to z/OS)
By the way, most (if not all) parts of z/OS were written in PL/1.
IBM OS/400 - V4.x, V5.x
zero vulnerabilities
(Note, that OS/400's kernel ("SLIC"), written in C++, is absolutely closed code (afaik you can't even access its machine code on the iSeries 400's DASD), so nobody outside IBM knows, what kind of bugs might be in that kernel; anyway, because of its single-level storage architecture, this system has hardware pointer-in-memory protection, which, as a side-effect, prevents many of the most dangerous kinds of exploits, for example overwriting of return-addresses, overwriting of function pointers and such; so it's impossible to "smash the stack" on this machine)
Conclusion:
===========
To err is human; as long as people use Assembler, C or similar programming languages, they will probably cause buffer overflows and similar bugs; for this reason, we should take advantage of more intelligent hardware architecture, including features like tagged pointers and special CPU instructions for modifying addresses (so you still can change a function pointer, but only if you use the correct instruction; overwriting it using instructions for copying data areas (MOV on intel) would cause the pointer protection hardware to invalidate the pointer). Better hardware is a good foundation for better software. "Protected mode" (memory protection, preemptive multitasking,
Use a suitable programming language to implement applications; you don't need to mess around with direct memory access, pointers and such, if you're programming software for accounting or a spread sheet application. Many commercial applications for z/OS and OS/400 are written in COBOL, PL/1, etc. rather than in C, and they do not seem to have nearly as many critical bugs as most C programs; OpenVMS people will tell you the same story, I don't know what programming language they used to write most of their applications, but I know it wasn't C.
If you can't get an open source Ada, Cobol, PL/1,... compiler, at least use C++ (use std::string).
Don't forget Java; java programs might not be as fast as compiled code, but especially non-GUI applications are still pretty fast, and Java is a well-designed language.
Unfortunately, there are no results for trusted operating systems such as Trusted Solaris; it would be interesting, whether the same bugs that are critical on standard operating systems could cause system access or any similarly critical escalation of privileges on trusted operating systems (my guess is, commonly not; these systems have extremely strong security implemented in kernel code). By the way, Solaris 10 will include many key security features that were only available in Trusted Solaris before (including privilege sets and compartment-like process separation).
Book hint: "The Inside Story of the IBM iSeries" by Frank Soltis, the system architect of the iSeries 400 (aka AS/400) and OS/400; especially interesting because of the fact, that this system's design is very different from common hard- and software architecture;
Most of UNIX's concepts are technically more consistent and logical than those of Windows.
..." and "tar -xvf ...". Plus you can build a program on one machine and then simply copy it to another one.
For example, because of the Windows registry you can't simply copy a program to a CD, then delete your harddisk, reinstall another version of Windows, and copy the program back to harddisk, because the program won't work anymore.
But you can do that on Unix. The concept of the Windows registry mixes all parts of the operating system, user applications, configuration files, etc. into one big datastructure. Windows even lacks any intelligent way of backing up and restoring a program and all its registry settings alltogether. That's one of the reasons why I still think, that Windows is a poorly designed operating system. On UNIX, a program is simply some files in the VFS tree. If the files are there, then you can run the program. Backup/restore is as simple as "tar -cvf
Another example is the concept of foreground and background processes on both platforms. Windows cannot run every process in background; processes need to implement special interfaces to run them at system startup, and you can only start and stop them by using the service control manager, you can't kill those processes.
On Unix, you can start any program at system startup as a background process. If that process won't stop anymore, you can kill it just like any other process.
That's what makes programming and using computers simple and logical.
Windows is probably more consistent in what the user sees (the look and feel of GUI widgets in different applications), because there is only ONE GUI subsystem, which is integrated into the operating system kernel.
However, comparing Windows with UNIX at the GUI level is somehow like comparing a banana with a tree. X11 is a (privileged) user space process running on UNIX, it's not an integral part of the operating system. Actually, the fact that X11 is simply just another user space process is a concept that adds some flexibility and also robustness to UNIX. If something in the GUI fails (the window manager, the desktop manager, the graphics device driver), you can simply kill and restart the entire GUI subsystem without rebooting; you can even install another graphics device driver without rebooting the OS.
Actually, sometimes when a window manager fails, I just kill the window manager and then reinsert it between the X client applications and the X server - even that works fine.
Anyway, X11 is not UNIX, it's just an application running on UNIX.
That makes 4 'virtual' CPUs. Anyway, as most PC users are running NT (or one of its successors), and as locking is anything but fine-grained on NT, while one thread running on one CPU will call some NT kernel function which locks a CRITICAL_SECTION, three other threads running on the remaining three CPUs, who call some other kernel function, will wait for the same CRITICAL_SECTION; effectively, only one CPU gets any real work done.
That's why some other OSs may perform similar on uniprocessor hardware, but may substantially outperform NT on multiprocessor hardware. For example, if you take a look at the SunOS kernel, you'll find much more efficient locking techniques (faster mutexes, lots of rw-locks, more fine-grained structures == better parallellization).
Multiprocessor hardware performs well with technologically sophisticated software only; I mean: it doesn't make sense to increase the number of processors if you don't use all of them simultaneously.
> Concerns about stability? Security? Dislike of Microsoft's business practices?
All of these, plus:
* i don't like the Win32 API; APIs like CreateProcess, CreateThread, FindFirstDirectory (or similar), FindNextDirectory - all of those are not very elegant designs;
* the registry is a misconception;
* windows will send any signal from any GUI process to any other GUI process, ignoring different security context; that's a security design error;
* it does not run efficiently on multiprocessor hardware;
* programs need to be especially designed and installed, if you want to run them as background processes (program must be a "Service"); what a stupid idea %-/ - and if they fail, you can not even kill them using a task manager;
In my opinion, the NT kernel is a bad design; i think, that's where most of the bugs come from (not because of bad implementation, but because of bad design).
This is an Intel Platform Edition machine (Solaris x86) .. there is definately something wrong with those color computations, and /usr/lib/signal.h defines DS, which scribus/seiten.h tries to use as a variable name for some kind of a Qt widget...
Now I finally got 1.1.6 installed on my Solaris box.
For all Solaris users:
Regarding the error on line 139 in scribus/seiten.h:
(parse error before numeric constant)
The code on line 139 is:
QCheckBox* DS;
On Solaris, and possibly on many other Unix System V Implementations, DS is already defined if something includes signal.h; to fix this error, place the following line into seiten.h (right after the #include statements):
#undef DS
I compiled Scribus on an Intel Platform Edition machine, which is a little-endian architecture. After installing Scribus, i got the following error:
xlib_rgb_init: compiled for big endian, but this is a little endian machine.
I tried a lot of modifications in gdk-pixbuf*.[ch] and in config.h to make it work, but it always starts up with a white page that turns red after about 1/4 second. If I choose red as background color for the page, the page turns darkgreen. Combinations of red and blue work, combinations of blue and green do also work.
I don't know what's wrong with the colors, but to me it seems like the developers of Scribus really messed up a lot of things regarding big-endian/little-endian dependent computations (I wonder where you need such computations in your code, when you just want to view an empty page.)
So, it theoretically works. Practically it doesn't, because the color computations are broken...
Either this is security-by-obscurity, which means, that I'll be able to listen to the same song as many times as I want to (for example, by simply restoring a 'safety copy' of the file, or maybe by circumventing application security (using a debugger)), or I must not be able to copy the file (or to open this file with any program other than Microsoft's WMA player), which effectively makes my computer unusable, because I can't use my own (or 3rd Party Software) on it anymore (then maybe it's still a Microsoft-CD-Player-with-integrated-Microsoft-Type writer, but not a computer).
/dev/fd0 or something, because that would allow you to copy the file's content. You must not be allowed to debug certain applications on your computer.
.. . What about DRM-protected viruses? There will be only a very small group of people who would then be able to isolate the virus.
Just imagine UNIX without the possibility of using pipelines, because only ONE specific program works with a specific file; you must not even be allowed to read from
Now imagine a cracker, who can get a DRM certificate for his newest virus (don't say, it's impossible
I think, we could find a lot of other potential 'accidents' with DRM technology.
DRM technology can't work realiably on open computing platforms, it will always be either totally insecure ('obscure' instead of 'secure'), or it will at least be potentially dangerous. Don't use it.
regards,
octogen
In my opinion, there is no substantial difference in code quality between open source software and proprietary software.
/usr/bin/env. Kind of confusing %-)
/usr/local, which is the default location) and Perl 5, just to compile some C/C++-Code?
:-) is Sun JVM vs. GCJ's libjava. I compiled a very complex multithreaded application using GCJ; it worked fine on uniprocessor machines, but it randomly deadlocked on my multiprocessor server. Finally I found out, that libjava is broken on SMP machines. That doesn't mean, that libjava's code quality is bad; but it still means, that some other Java-Libraries (those of some virtual machines) are more mature, and possibly better tested.
I have seen a lot of very buggy commercial software (including nVidia drivers, IBM's LANManager Services for OS/2, lots of Microsoft's services and utilities in Windows 2000 (for example, "TCP/IP Helper Service") and Netscape 4.7).
On the other hand, I have also seen very bad code quality in open source products - for example, GTK+ (actually, the really bad thing about GTK+ is primarily its install scripts, makefiles and such). Compiling and installing GTK+ on anything else than on a GNU/Linux-machine is some kind of an adventure, while its commercial counterpart, Qt from trolltech, can be compiled quite easily.
- I set the PKGCONFIG env variable before running 'configure'. It worked quite well until line 27.000 (or so) in 'configure', where the variable's content was suddenly gone (BTW, I really dislike debugging 28.000+ line shellscripts). I tried to 'configure' with bourne shell and with korn shell 93.
- It assumes, you have Perl installed (if it's not in your PATH, 'configure' creates funny things like "#! -w" instead of "#!/path/to/perl -w"). The error message produced due to this bug was something like '/usr/bin/env: no such file or directory' - because the perl script was directly started using
- 'configure' forgot to add '-fPIC' to CFLAGS, for this reason all shared libraries where broken. I had to add this option manually.
- Nothing works with 'make'. I had to install 'gmake' (GNU make) instead.
- The actual source code of the core libraries finally compiled, after I had upgraded to gcc 3.3.2. The source code of the 'demo' programs was totally broken, and gcc refused to compile it - once more I had to change the makefiles manually.
-----
One or two weeks later I compiled trolltech's Qt library on the same computer. It was as simple as './configure --platform=platformname && make && make install'.
Why do I need to debug 28.000+ lines of shellscript-code and a lot of makefiles, why do I need to install gmake, pkgconfig (by the way, pkgconfig and most other things in GTK+ don't work well if you don't install everything to
Qt does mainly the same as GTK+, but it simply compiles, using only shellscripts, 'make' and a C/C++ compiler.
Another example regarding code maturity (rather maturity than quality, notice the difference
-----
Some fundamental things about Software:
- The more people read the code, the more people can potentially find and fix bugs (good about open source).
- If a lot of people are allowed to write the code, somebody has to coordinate the work of all these people. Lots of different versions of the same module, written and/or modified by lots of different people need to be combined or coordinated otherwise (bad about most open source projects, because hardly somebody knows, how trustworthy anyone of the developers is; good abous some closed source projects (e.g. Trusted SunOS kernel, IBM SLIC kernel and other trusted code), because only a small group of really good programmers is allowed to write or modify code).
Conclusion: It's good to have only a small group of 'trusted' developers, who write or modify the code, and then to let everyone else read and verify the code.
regards,
octogen
I've been using Solaris x86 several years now, and it is still my favorite UNIX OS on the x86. As far as I can tell from my experience, its kernel is more sophisticated than the Linux kernel (kernel level audit trail, ACLs, fine grained locking, ...), especially regarding smooth multitasking/-threading under very high system load.
There is also a very interesting version of Solaris, called Trusted Solaris, with very strong security.
And remember, all versions of Solaris x86 run very fine on SMP machines; it still seems to be more scaleable (or more efficient on big machines) than Linux and/or BSD.
Maybe you should disable ctrl-alt-del in your /etc/inittab.
Funny, I had pretty much the same idea... I use my own C library (which is called "secureStrings") for my programs for some time now (about one year), because it has always been my opinion, that things like strcpy() and strcat should become forbidden ;-). SecureStrings works on Unix, VMS and OS/400; i didn't try, but it probably also works on NT...
C or C++ is probably great, for writing very special code, such as kernel modules to support new hardware, or scientific software and such.
However, I think there should be a more secure programming language than C for commercial and for networking software.
Implementing things like a webserver, a data warehouse, accounting software, etc. in C/C++ can be extremly dangerous, and experience shows, that most programmers just can't do it the right way with C/C++.
On Mainframes and AS/400s most commercial applications are written in COBOL, and this is probably one of many reasons, why these systems usually don't get hacked.
However, COBOL is somehow unhandy (unconventional syntax)
On Unix you can hardly get something else than a C/C++- or a Java-compiler; there should be an Ada- or a Pascal-Compiler available for every Unix derivate.
oops, this looks like an intranet URL.. sorry..
here's the correct link:
Martin Logan Statement E2
Thanks god there is a difference between GOOD and LOUD sound (re)production:
For $80.000,- you can buy this loudspeaker, whose sound quality is much more impressive than the loudness of any dB drag race car on this planet...
Sun/Solaris has a release that is C2 compliant, but very expensive.
The standard Solaris release is C2 compliant. The very expensive one is a B1+ compliant OS called "Trusted Solaris".
where C2 or B1 might be required.
At least C2 security should be the standard on every server which is used for commercial applications (storing private data, processing business transactions,
Servers which store credit card numbers or something like that may not need to take sensivity labels into consideration, but they should at least be split into separate compartments for each application.