POWER to the People

Today’s blog is courtesy of Mark Olson, WW Product Offering Manager for Power Systems, who teams with IBM developers to prioritize, announce and roll out new generations of Power Systems hardware. His post complements the latest chapter to be released on facebook in celebrating 25 years of IBM i. Enjoy it, and then join the conversation.

I’m honored to have been asked to contribute a few words about some of the amazing hardware IBM i clients can use today. Power System hardware offers capabilities, capacities and price-performance levels that were almost unimaginable 25 years ago.

The core (pun intended) is the POWER chip. It’s interesting to note that, unlike Watson, which used off-the-shelf POWER7 hardware, achievements like Deep Blue used custom designed/built servers. Deep Blue defeated the champion chess master, Garry Kasparov, in 1997 in a six-game match using custom chips that were specifically built to analyze chess moves. You wouldn’t use Deep Blue to run your business. POWER chips, on the other hand, were built to handle an immensely wide range of uses.

The POWER chip technology running IBM i was the output of many, many developers–including teams of IBMers from Rochester and Austin. Prior to POWER, both the AS/400 and the RS/6000 servers had their own chips that were similar, but different. Development teams collaborated over several years to incrementally evolve the chips and underlying operating systems to accomplish a blended, optimized chip that could run IBM i, AIX and Linux operating systems. 

It was important to ensure the key values of both the AS/400 and RS/6000 were implemented. One of the key attributes implemented specifically for IBM i and its single-level storage was address protection. This is sometimes called the “65th bit”. For you technology purists, this isn’t really an additional bit in the chip, but is a tagged pointer implemented in the chip and its execution units. It means that the hardware prevents addresses from being compromised. It’s a key reason why the underlying security and protection of IBM i is so good.  

Today’s POWER7+ chip is a marvel of engineering and manufacturing. Thirty-two nanometer technology. More than 2 BILLION transistors per chip.  L2 and L3 cache on the processor chip.  Up to 8 cores per chip.  Ranging from 3 to 4.4 GHz.  Wow. 

Power Systems servers are of course more than just the POWER chip. Every generation of chip is supported by an integrated set of related hardware. This includes plenty of fast memory, memory controllers, memory buses, I/O buses, PCI slots, power supplies, service processors, expansion drawers, suites of PCI cards, an assortment of HDD and SSD, etc, etc, etc.  And, of course, it depends on great architectures tying them together.   

Let me highlight a couple of really sweet capabilities. IBM publishes a GHz value associated with each server. For example, a Power 720 can be 3.6 GHz. But the chip doesn’t always run at 3.6 GHz. If you are running extremely high workloads on the server, it will automatically take its temperature and, if cool enough, boost the GHz a few percent higher to help handle the peak workload. Or conversely, if the server is not busy, several options are available to the system. If some of the processor cores aren’t being used at that point in time, they may slow down or even take a nap for a few milliseconds. This is done on a per-core basis, not a per-chip basis. The system does this without impacting your performance. If you authorize the system to do so, work that doesn’t have to be done as quickly as possible will be handled with lower GHz. For example, if you have a batch job which is due at 6 a.m., but it’s currently 1 a.m. and only needs two hours to complete, you can tell your server it’s OK to take longer and it will run at the lower GHz, saving energy and cooling, and still finish before 6 a.m. That’s a “cool” capability. 

Another new technology that’s becoming more and more popular is flash memory, also known as solid state drives (SSDs). This is rapidly evolving and its performance, reliability and price/performance, already very good, keeps getting better and better. Today you can configure flash memory on Power Systems servers in a variety of ways. It can be in an “external” storage device like a SAN attached through a Fibre Channel connection, or it can be an “internal” storage configuration leveraging IBM’s premier SAS infrastructure. Three different “internal” configuration options are available to match different price points and other selection criteria. All of the flash memory options I’ve described can make a huge performance difference if your server has an I/O bottle neck or if you want to implement a new application for which I/O performance is critical. The nice thing about IBM i and SSD is that IBM i has the highest level of integrated capability of any operating system to effectively use SSD. For example, in addition to a user being able to assign data base objects to SSD, IBM i can determine what’s hot and what’s cold and, while the user application is running, migrate the hot data to SSD and the cold data to HDD. IBM i can even do that if the SSD is in a SAN. Or IBM i can leverage the Easy Tier capability of IBM SANs to implement hot/cold data across SSD/HDD. You have a lot of flexibility.

I could go on, but I won’t. Thanks for letting me share a few thoughts. Happy Birthday IBM i!!!

Separated by Oceans, United by Purpose

To help celebrate the international scope of the IBM i business, our guest blogger today is HaiBo Yu, Senior Manager for IBM i database, Web integration & Lotus development at the IBM China lab in Beijing. His story illustrates how, when it comes to IBM i, integration is about more than the product, it’s also about the team. Read it, and then join the conversation on Facebook.

My first impression of IBM i was formed in a conversation nearly a decade ago: “Rochester takes a lot of pride in the iSeries as one of the most reliable, scalable and easy to use platforms in the world. We think a lot about what things mean to our iSeries customers…, they are much more interested in running their businesses…” I heard this from Jeff Vettel, the first Rochester, Minn., colleague I met when we established the team in Beijing to work on IBM i projects in 2004. From Jeff’s words, I realized the great value and differentiation this platform offers and told myself that I would try my best to keep the great reputation our Rochester team has built in the IBM i community. This has been kept in mind and passed on to anyone who has since joined the team.

Time goes fast. Many of us were single when we established our strategic relationship with the Rochester team, and we have since gotten married and had children! At the same time, we have delivered a lot of good things together with the Rochester team in IBM i 5.4, 6.1 and 7.1. And we have gradually accepted more responsibilities in our work too. We started with small projects, mainly on testing, but were eventually able to work independently in areas the China team covers. For example, we not only have developers and testers working on key features, but also have strong leaders participating on the business architect team led by our Chief Architect, Steve Will, for setting overall strategy and doing release planning.

The China team understands well what the key factors are for IBM i to be a successful platform running serious business applications. We believe and are deeply integrated into the culture the Rochester team has created – the processes to ensure high quality, the tradition to think in a customer’s way and the spirit of innovation to meet the needs of an evolving business environment. As we’ve grown, mentoring from the Rochester team has always been important. A lot of people in China, including myself, have mentors in Rochester. This helps us not only develop deep skills and business insights, but also be truly integrated as a global team. We do appreciate the efforts of our mentors, and we also remember to enjoy our time together when we get a chance to meet each other face to face either in Rochester or in Beijing.

With a strong development team in Beijing, we hope we can benefit our local market and customers too. We have established various channels and programs to help them. In China, we have an annual IBM i event named iWorld where IBM, customers and business partners gather together to discuss the latest updates of IBM i and share experiences. Our development team is involved to help plan the agenda and provide speakers and support staff. Besides that, throughout the year we also hold several Study Tours to invite customers and business partners to our lab for workshops and discussions about IBM i strategy, hot technologies and other topics of interest to them. We also have one-on-one interlocks with some customers for their unique questions/concerns. With our support, Chinese customers feel they are bridged with the WW community, know more of what global customers are doing and have more influence as to what this platform should do to meet their needs for business growth. Besides that, we have had chances to talk with WW customers when we attend LUG and COMMON, or do presentations at the Rochester briefing center. Meanwhile, our Rochester colleagues also have opportunities to speak with and meet Chinese customers during our Study Tours.

What will you be doing in 2020? None of us have a clear answer about ourselves yet, but IBM i’s support life cycle already extends beyond 2020 with our current planned deliverables. I’m looking forward to the next celebration of IBM i with my colleagues and customers all over the world, and also my grown-up daughter at that time…

 

 

 

 

Security and Integrity – Definitions and Why You Should Care

The IBM i 25^th anniversary celebration continues today with a focus on system integrity. Our guest blogger on the topic is Jeff Uehling, security architect for IBM i and a member of the IBM i development group in Rochester, Minn. Read Jeff’s post and then join the conversation on Facebook.

All operating systems and add-on security products that exist today provide the basic security capabilities one would expect, including user and password management, the capability to authorize a user to specific resources, some level of audit capabilities, network security interfaces like SSL and encryption interfaces to help protect your sensitive data. However, the level of security functionality provided tends to vary greatly from platform to platform. This is especially true in areas like security management (management, monitoring and reporting interfaces) and the richness of audit features. On IBM i, you have all the interfaces needed to set up and manage all areas of security and audit as well a secure run-time environment. These integrated operating system capabilities provide for the capability to set up a very secure environment on which to run your business.  

Before getting into a discussion on system integrity, I need to briefly discuss the Technology Independent Machine Interface (TIMI), often referred to as the MI layer of the IBM i server. TIMI provides a flexible interface upon which the operating system is built. The MI provides a significant architectural advantage that other servers available in the marketplace cannot match. This layer allows the underlying hardware and microcode to change without impacting the operating system and applications that sit on top of it. (See “TIMI – Protecting Investments and Integrity in IBM i”) I bring this up as this is very important, not only because the MI layer provides a way for underlying hardware and microcode to change, but also from a security and integrity perspective. The MI layer has allowed us to make numerous changes over the many releases of this platform in a manner that constantly improves its security and integrity capabilities without disrupting your production applications. 

So what’s the difference between security and integrity? I’ve already discussed security and the features involved, like user and authorization management, audit, encryption and network security. All of these features are important and necessary to provide for a secure run-time production environment. However, without system integrity these features are somewhat meaningless. How can that be? And why should you care? System integrity mechanisms built into a server ensure that all of the security controls and interfaces implemented in the operating system and microcode cannot be bypassed or compromised. In other words, system integrity mechanisms ensure that the security mechanisms being used to protect your data are actually in place, being run, enforcing the controls that are intended to be in place, and cannot be compromised. If one can find a way to bypass these security checks, the integrity of the system can certainly be questioned. System integrity mechanisms should ensure that all the security checks that an operating system needs to perform are performed and enforced, as well as all audit data that the operating system and microcode need to generate is generated and accurately logged. Certainly one can see the importance of the system integrity mechanisms, because without strong integrity, the security capabilities and thus your data accuracy can be questioned.

IBM i has a history of system integrity enhancements. For example, with innovations implemented in release 6.1, each and every object on IBM i was changed to be protected with the latest integrity features available in the POWER hardware. Hardware Storage Protection, which has been available in the POWER processors and used on IBM i for many releases to protect objects and control blocks, was enhanced to further protect these objects. The new level of Hardware Storage Protection prevents direct access to data objects on IBM i, even protecting these objects from an altered or patched operating system program. What this really means is that the integrity characteristics of IBM i objects, including programs and data files, have been enhanced to industry leading strength. These leading edge integrity changes will provide critical security and integrity protection for customers running IBM i in their businesses going forward.

In summary, I hope I have made a case for having both security and integrity in IT platforms. Along the way, we have looked at the many security features integrated with IBM i on Power Systems and discussed its leading edge system integrity characteristics. I’ll leave you with one open question you can discuss in your organization: Do all of the OTHER production servers you use to run your business have the necessary security AND system integrity characteristics required to protect your applications and data against the constant threats inherent in today’s network accessible world?  

Thank you very much for your time!

 

 

 

IBM i 25: Object Orientation

Today’s IBMi25 chapter is Object Orientation. You can find it on our Facebook page: bit.ly/IBMi25. Today’s guest blogger is Terry Ford (taford@us.ibm.com), who works in IBM’s Lab Services organization with a specialty in security.

As an “old-timer, ” my career started out as a System/3 programmer at a local government shop in Illinois. When I was introduced to the AS/400, the notion of object orientation was foreign and unsettling. I thought, “Am I going to need to relearn everything?” Needless to say, those concerns quickly disappeared once I learned the basics of object orientation and the benefits it provides.

The AS/400 architecture, which carries forward to IBM i today, offers a distinct advantage over other platforms in the marketplace. With its object orientation, the operating system works through a comprehensive set of interfaces to define the operations that are allowed for a particular type of object. Each of these operations includes security as a base component that enforces a very stringent set of rules based on the object types on the system. For example, you can call a program but you can’t call a file. You can run a command but you can’t run a data-area object. Calling a program requires one set of authorities, while running a command requires a different set. On other systems that don’t have an object orientation, however, everything is a file. Rules can’t easily be implemented on these systems that could prevent someone from running malicious scripts stored in a document or file. Generally, opening a file on these systems requires the same level of authority, regardless of the file type, and thus it’s much more difficult to control access.

Recently, while performing a security assessment on a customer’s system, IBM i object orientation proved very helpful. A commonly used exploit on file-based systems is to place a Trojan Horse in the system path. Trojan Horses could be anything - not necessarily a file with an .exe or .bat extension. On IBM i, if the exploit is to be present, it must be an object that can be called through OS-approved interfaces. Through security assessment software developed by Lab Services, we were able to identify for the customer some programs that had been placed in the operating system library and had the potential for subverting defined security controls. This was easily detectable because of the object orientation of IBM i, which allowed us to quickly mitigate the threats on the customer’s system.

In the past year, we have improved our security assessment tool to isolate threats more quickly and present them in a dashboard. From a central location, a customer can look across his enterprise and see how well its security policy is being administered. This dashboard is a synthesis of more than 1,000 pieces of statistical and static information that define security for a system and includes analysis of users, work management, networking, applications, system configuration and more. User defined options allow a customer to enhance the reporting and grading of results. All of this was possible because of the object orientation of the IBM i operating system. Object orientation does not prevent someone from trying to create malicious software, but it does make some kinds of attacks impossible, and makes identifying the rest much easier.

 

 

TIMI – Protecting Investments and Integrity in IBM i

Today we deliver the next in the series of 25 chapters that are helping us celebrate the IBMi25 campaign, and today’s topic (bit.ly/ibmi25) is clearly one of the major reasons the IBM i operating system has endured while other platforms created around the same time have disappeared: the Technology Independent Machine Interface, affectionately known as TIMI.

I have written briefly about TIMI twice before; once in “The Layers of i” and again in “Why IBM i? Architectural Foundations.” Today, I’ll summarize what I said there, and go a little deeper to explain more of the value of this incredibly powerful piece of the operating system.

TIMI is both easy and difficult to describe. To an application, TIMI is a contract. TIMI provides interfaces that perform known functions, and the contract promises that those functions will continue, unchanged, no matter what hardware platform is used to implement them. This is a pretty easy concept, but how is it accomplished?

Each program that is compiled on IBM i gets turned into a set of TIMI instructions. Essentially, it gets compiled down to a set of intermediate code. For decades, that’s been a pretty common step for a compiler to take – get to an intermediate representation of the program before creating the machine-level instructions. One big difference, though, is that the compiler on IBM i does not go any further. It leaves the intermediate code connected to the program object, and then the lower levels of IBM i act on the intermediate code to translate it into the instructions used by the Power hypervisor and Power processor beneath the OS. IBM i does this only when necessary, not every time the program executes. Typically, the translation takes place once when the program is moved from one release of the operating system to a later one, and never again while it runs on that later release.

This architecture has allowed programs that were written decades ago, even as far back as the System/38, to run on each release of the operating system without being recompiled. As long as that intermediate version of the program is still attached to the compiled object, the translator can turn the program into executable instructions on the system.

Certainly operating systems may have a subset of their Application Programming Interfaces that guarantee that programs that use them will continue to work in the future, but even in these instances the programs must be recompiled. IBM i guarantees that a program, once compiled, will continue to run on any future version of the operating system without recompilation. Other vendors in the 1980s and 1990s tried to incorporate new system technology by forcing their users to recompile, and sometimes even to drastically modify their software. Faced with having to make significant investments, when they had already spent good money developing the software the first time, customers of those vendors were forced to examine whether they wanted to remain on a platform that did not protect their investments in the first place. Large numbers of those customers left, and the rest, as they say, is history.

As if that level of investment protection were not enough reason to appreciate TIMI, it also provides a level of system integrity that has made IBM i one of the most stable and virus-resistant platforms in the market.

Most of my readers have a background in computer programming, and they would have a basic understanding of the concept of a “pointer” in a programming language. For those of you who don’t have such a background, a “pointer” is used to perform an operation on a piece of data stored in a computer’s memory. But, you see, the memory is also where the program itself runs, and it is also where the operating system runs. Everything that runs on a computer runs in the memory. Programs need to have pointers to the data the programs are using. But, if a program has an errant pointer into memory that it should not have, it might write into that memory. And if it can write into that memory, it could put erroneous information into the memory, causing the program to perform erratically. It could even insert malicious code into the program or into the operating system.

On IBM i, this cannot happen. It is architecturally prohibited because of TIMI and the way TIMI’s instructions get translated and run on the Power processor. As I mentioned above, each user program is compiled to an intermediate form, so all uses of “pointers” in those programs are also in intermediate form. The pointers created by user programs are not allowed to point at the parts of memory used by the operating system, so there is no way those user programs can possibly harm the OS, nor can they place malicious code into it. This protects the integrity of the operating system – keeping viruses and other malware from tapping one of their most insidious paths into a system.

I’m afraid I have simplified this quite a bit, and I have only scratched the surface of the power TIMI brings to the IBM i operating system, but I hope I’ve given you a feel for just how critical its role has been in ensuring that our clients can move forward as technology changes. After all, the only thing we can always be certain of, when it comes to technology, is that it will change. Having an architecture that doesn’t simply tolerate change, but at its core was built to embrace change, ensures that your investment and your system will be protected long into the future.