Thank you Guus. Are you suggesting we should open a case? Can you tell me which scripts you need me to run please?
Original Message:
Sent: Tue October 19, 2021 04:52 AM
From: Guus Bonnes
Subject: zSecure alerts during IPL
Yes, that's what I used in my testing, and it helped me get rid of some "false positives", especially the one for ICSF.
I guess it now goes beyond discussion in a public forum to determine what causes the alerts. For example, I would like to see which SVCs trigger the alerts, and the contents of the variables. That involves running some extra carla scripts using the temporary EM-CKFREEZE files (the one from before the IPL, and the first one after it).
One of the reasons that the alert still triggers might be that the SVC code has relocatable constants (addresses) in the beginning of the code.
------------------------------
Guus Bonnes
Original Message:
Sent: Tue October 19, 2021 04:03 AM
From: Anji Stephens
Subject: zSecure alerts during IPL
Hi Guus,
I have tried your suggestion, but unfortunately there are still the same number of alerts being generated.
Just to confirm, I am using:
COMPARE=(curr_contents,curr_apf)
Is this correct?
Thanks and regards,
------------------------------
Anji Stephens
Original Message:
Sent: Mon October 18, 2021 04:32 AM
From: Anji Stephens
Subject: zSecure alerts during IPL
Thank you Guus. I will try that and get back to you.
Regards,
------------------------------
Anji Stephens
Original Message:
Sent: Mon October 18, 2021 03:33 AM
From: Guus Bonnes
Subject: zSecure alerts during IPL
Yes, a custom alert will do: in the compareopt, change curr_address into curr_contents (one line).
An actual product change might be FIN.
------------------------------
Guus Bonnes
Original Message:
Sent: Fri October 15, 2021 12:53 PM
From: Anji Stephens
Subject: zSecure alerts during IPL
Guus, when you say a change to the code, is that something we can do with a customised alert, or are you talking about a PTF? If a PTF, do you have any idea when it would be available please?
Thanks,
Anji
------------------------------
Anji Stephens
Original Message:
Sent: Tue October 12, 2021 02:28 PM
From: Guus Bonnes
Subject: zSecure alerts during IPL
Hmmm, that's not exactly what I said. A change in the address indicates that something has changed in your IPL process. And as such it's not completely useless. The only SVC that normally jumps around is the one for ICSF, because it's installed dynamically, and is dependent on the timing of the ICSF start command.
I'm not in favor of simply discarding all extended monitoring alerts if it's the first compare after the IPL. Suppose that somebody inserts a new SVC, you'd definitely want an alert about that.
The minor change that I was thinking about, and that I needed to test was a change of the compare fields. For example, change the alert to compare not the address, but the first 256 bytes of the code. That might also trigger on an address change, but is less likely, and at least will continue to trigger on all significant changes, even across an IPL. I'll suggest to change the code accordingly.
------------------------------
Guus Bonnes
Original Message:
Sent: Tue October 12, 2021 04:35 AM
From: Rob van Hoboken
Subject: zSecure alerts during IPL
As Guus points out, it makes no sense for alert 1603 (and possibly other COMPAREOPT based alerts) to complain about a change of the entry point address after IPL. In essence, the IPLDATE (lookup?) value from the snapshot CKFREEZE should be a COMPAREOPT BY= field, at least for the SHOW=CHG function. I am not sure if COMPAREOPT supports lookup specifications, but that's what seems to be necessary to fix these incorrect alerts.
Automatically deleting snapshot CKFREEZE data sets after an IPL, as Guus suggests, is a workaround that the customer could build, though it nixes the design purpose of these data sets: why else keep a configurable number of these at hand, other than for forensic, after the (alert) fact analysis.
------------------------------
Rob van Hoboken
------------------------------