How a z/OS Portable Software Instance can help you prepare for the "front end" of z/OS Validated Boot

on

 


No doubt, you hopefully have heard about the new z/OS Validated Boot function! In short, this is a solution which employs digital signatures for an IPL-time verification to ensure that the IPL data has not been tampered with, and that you can verify the source.  This is a fairly large solution, that encompasses both software (z/OS V2.5 and higher) and hardware (IBM z16 with appropriate microcode) support.  

What I wanted to specifically discuss is what you might see in your next z/OS V2.5 z/OSMF portable software instance (aka "ServerPac"), which provides some support for z/OS Validated Boot.  I'll limit my discussion to just what you'll encounter during the z/OSMF Software Management deployment with the PostDeploy Workflow.  This is a portion of the z/OS Validated Boot "front end" work you perform, to actually sign the IPL data from your driving system to your built target system.  When you are done with the "front end" work, you would then move into the "back end" portion which is where the built-and-signed target system will actually be validated during the IPL process.  

Needless to say, the front end and back end are associated with each other because what you sign on the front end (during product installation or maintenance), is what you'll be validating on the back end (during IPL).  

The most important thing when you encounter this z/OS Validated Boot support in the z/OS V2.5 ServerPac PostDeploy Workflow, is to make sure you read the comments!  If you choose to sign your IPL artifacts, you must have the proper security configuration completed and a z/OS V2.5 driving system with PTFs for z/OS Validated Boot installed.  And, you even must have the proper target system PTFs for z/OS Validated Boot on your newly installed target system - which is a fairly unique situation when running a step in the PostDeploy Workflow.

Notice I mentioned above about making sure you have the right PTFs installed on the driving and target systems.  What are those PTFs?  Of course, we'll use our favorite felines (fix"'CAT"s)!

  • Driving System PTFs:  Use SMP/E FIXCAT IBM.DrivingSystem-RequiredService or IBM.Function.ValidatedBoot
  • Target System PTFs:  Use SMP/E FIXCAT IBM.Function.ValidatedBoot
  • (It just so happens that all the z/OS Validated Boot also have a FIXCAT of  IBM.Device.Server.z16-3931.Exploitation)

It goes without saying, there is lot of documentation on setting up the security environments, preparing the driving system, preparing the target system, and finally actually indicating that you want to validate your z/OS when it IPLs. If you are going to use this function, you definitely need to carefully read all the details.  The best place to start would be the z/OS Validated Boot Content Solution, here.  

So let's jump ahead a bit...let's say you've got all your security configuration work done on your driving system "front end".  At this point, you may or may not have prepared your "back end".   Actually, does it matter if you sign your z/OS V2.5 target system artifacts if your back end system isn't ready yet with the correct HW level and security configuration?  The answer is NO.  Because signing the artifacts to prepare for Validated Boot is a compatible activity.  Meaning, you can sign now and validate later.  You can do a traditional IPL (known as a Channel Command Word IPL or CCW-IPL) on signed artifacts that may be used for a future Validated Boot IPL (known as an List Directed IPL, or LD-IPL).  Sweet.   By the way, with z/OS Validated Boot you can do an LD-IPL in Audit Mode, as opposed to Enforce Mode.  In Audit Mode the IPL can proceed, even if it encounters validation errors.  

Hopefully at this point, you've got some basics in your head about the big tasks of z/OS Validated Boot, and a good idea of the requirements you need to take to exploit it.  Remember, compatibility is there, so you can phase exploitation by doing front end signing work first, and back end validation at IPL time later on, when you're ready.  

 Finally...the point of this blog post...what will you see when you deploy your z/OS V2.5 portable software instance, using the PostDeploy Workflow?  You'll see three updates to the Workflow steps:

  • Create IPL Text
  • Stand Alone Dump Text
  • Program Signing

The first two steps, you probably know extremely well!  However, you'll see they look a little different now as the PostDeploy Workflow will be asking you if you want to prepare for z/OS Validated Boot.

Create IPL Text

Here's what you'll see for when creating IPL text in the PostDeploy workflow, with the circled part being the new addition.  NO is the default.  If you say YES ensure that your driving system is prepared or the step will fail when the job is run! 


Create standalone dump IPL Text

Very similarly, here's what you'll see for when creating standalone dump IPL text in the PostDeploy workflow, with the circled part being the new addition.  NO is the default.  If you say YES ensure that your driving system is prepared or the step will fail when the job is run! 


Sign in-scope load modules for z/OS Validated Boot

Here's where you will encounter the optional new step for signing in-scope load modules.  This job is customized for the data sets in your z/OSMF portable software instance which are deemed currently in-scope for z/OS Validated Boot.  Specifically, your NUCLEUS data set and all LPA-eligible data sets. 

  • If you want to exploit Validated Boot, you can use this PostDeploy workflow step to sign the applicable load modules on your target system.  
  • If you don't want to exploit Validated Boot, you can skip this step.  You can return later if you decide you want to exploit Validated Boot down the line.  

It is very important to remember here, that you must have the correct PTFs on your target system before you run this step.  For Validated Boot to succeed, the load modules signed on the target system must be those that support Validated Boot themselves.  So, heed the warnings in the produced job, run an SMP/E REPORT MISSINGFIX for IBM.Function.ValidatedBoot on your target system's CSI before you continue.  If you don't have the correct PTFs on your target system, the job might succeed and yet when you perform an LD-IPL, it will fail.  

As you can see, there is very little you have to answer for this new optional step:


I'll show you a snippet of the JCL job that is produced below.  Notice what is happening in this job.

  • all load module members of in-scope data sets will be signed
  • signed load modules take up a little extra room in a data set.  Therefore, your z/OSMF portable software instance has increased the freespace of these in-scope z/OS Validated Boot data sets.
  • a compress will be done after a data set is signed, to removed unused space between members.    


Final advice

Well, that's the extent of the "front end" that you'll see in your z/OS V2.5 z/OSMF portable software instance!  One final piece of parting advice. Even if you are not ready to exploit z/OS Validated Boot, you can save these PostDeploy workflow jobs and run them anytime you wish.  In fact, after you put on PTFs to those in-scope signed data sets you'll need to do just that:  rerun the signing job that you initially ran during your z/OS installation because the affected/updated members will have become unsigned during the SMP/E APPLY processing and will need to be re-signed following the PTF installation. 

For additional reading - especially on setting up the "back end", here's some handy links:

Comments

Post a Comment