Is the IBM i secure or irrelevant? 16 bit pointers

31 12 2009

In my previous post, I pointed out that the internet is the most complex system in existence. I also promised insight regarding security issues relating systems attached to the internet. Although the first and most important way to prevent security breaches is to keep your system patches, PTFs, fixes, etc. up to date, the subject of this post is IBM i (i/OS).

I see a lot of articles and discussions about whether IBM i is really secure or just so old that it’s really irrelevant. In point of fact, it’s very difficult to find any hard information explaining the how or why of IBM i security or lack thereof. To treat the subject fairly requires a book, so I will only address one small aspect of IBM i security today – 16 bit pointers.

First, 16 bit pointers have what’s called tags associated with them. That makes the pointers actually 18 bits with two bits that only the kernel (System Licensed Internal Code) can access. If these pointers are changed outside of a kernel operation, one or both of the tag bits get reset which invalidates the pointer. Although it’s not apparent to high level languages, the system is designed so that all information, on disk or in main storage, is accessed via these pointers. As a result, all information is addressed as though residing in main storage; hence, the term single level storage.

The system also organizes storage and uses the pointers in such a way that a program cannot go outside of the bounds of its assigned storage without causing a system exception. In addition, no program, procedure or data object – files, data spaces, queues, etc. – gets accessed without full kernel validation using these pointers. This validation includes access, operation and management rights verification against the user profile whose authority rights are being used to access the object. To protect the system against outside manipulation, certain system critical objects, including user profiles, cannot exist outside of the system Auxiliary Storage Pool.

Due to the design of these pointers and their use by the kernel, a worm or virus cannot take control of a program and trash or corrupt the kernel or access unauthorized information so long as the system runs at security level 40 or above. More about security levels at another time.

This only touches on one aspect of IBM i security. However, the security of the most security capable system in the world depends on
1. The competency of the system administrators
2. Limiting user authorities to only those needed to perform the required jobs and
3. Properly securing assets including passwords.

To dig deeper into aspects of pointers and IBM i internals, read the following. Some of the articles are outdated but still contain important information. Also, some of the articles contain specific information that enhances understanding of IBM i in addition to repeated information from other articles.

Notes for Storage Research by David McKenzie

AS/400 Memory Management from Inside the AS/400 by Frank G. Soltis

Architecture of the IBM AS/400 by Vincent LeVeque at James Madison University, document CS511 dated March 2001

An Object-based Systems Architecture from Smalltalk Musings by Richard Demers

Use the MI to Work with Pointers in ILE RPG by Junlei Li in MC Press Online

The AS/400’s Architecture Goes Beyond Technology by Frank G. Soltis via SystemiNetwork

OS/400 Storage Management from the IBM Information Center

Materialize Pointer (MATPTR) from the IBM Information Center

Resolve System Pointer (RSLVSP) from the IBM Information Center