search

SDL-Hercules-390 / hyperion

The SDL Hercules 4.x Hyperion version of the System/370, ESA/390, and z/Architecture Emulator
Other
246 stars 92 forks source link

Handcrafted (malformed) "card deck" crashes z/VM #554

Closed MockbaTheBorg closed 1 year ago

MockbaTheBorg commented 1 year ago

Hi Team,

I encountered an issue while attempting to import a text file into the reader. In order to reproduce the issue, I created a "malformed" card deck with an incorrect header card, as shown below:

USERID MAINT620 TEST TEXT C
THIS IS A TEXT FILE
NO MORE LINES AFTER THIS ONE
OR MAYBE NOT

The reader is configured as: 000C 3505 localhost:3505 sockdev ascii trunc eof

The deck was submitted via: HercRdr32 127.0.0.1:3505 <filename>

As a result, it caused a "crash" and IPL on z/VM. This behavior is consistently repeatable.

When I entered an incorrect username, such as "USERXXX," I received a message stating that the user was not in the cp directory, but there was no crash. However, when I used a correct username, such as "MAINT620," the crash/IPL occurred.

Decks with well-formed card headers seem to work without issue.

I have attached my current configuration file, z15.cnf.txt, below. Please let me know if you need additional troubleshooting information:

Thank you, Marcelo.

Fish-Git commented 1 year ago

USERID MAINT620 TEST TEXT C

When I entered an incorrect username, such as "USERXXX," I received a message stating that the user was not in the cp directory, but there was no crash. However, when I used a correct username, such as "MAINT620," the crash/IPL occurred.

  1. May we presume then that the version of z/VM you are using is z/VM 6.2? Have you tried a newer version, such as 7.1 or 7.2 or 7.3? Does the same problem occur with them?

  2. May we see your complete Hercules logfile please?  (for a test run without a OSTAILOR QUIET statement in it!!) (Or with it changed to OSTAILOR VM instead!!) *`()`**

  3. From the description of the error, this sounds more like a z/VM bug than a Hercules bug, since z/VM is the one that is crashing, not Hercules. That is to say, based on the description of the problem, I can't see how Hercules could possibly be causing this problem. It's not going to do anything different when one userid is used as opposed to another. It's going to do the exact same thing. So the problem (bug) is obviously in z/VM and not Hercules.

*`()** _I wish people would **stop** using **ostailor quiet**!! &nbsp;Especially when reporting problems!! &nbsp;It hides things that might be important with respect to the problem being reported!!_ &nbsp;>:-(`

Fish-Git commented 1 year ago
  • z15.cnf.txt

FYI:  you don't need any of the FACILITY statements you have in your Hercules configuration file (except maybe 55, but I'm doubting you even need that one either). All of the facilities you are enabling are already enabled by default. Enter facility query all (or facility query long or facility query xxx, etc) for a list of recognized facilities and which are enabled by default and which are not. (see help facility for more information.)

MockbaTheBorg commented 1 year ago

USERID MAINT620 TEST TEXT C

When I entered an incorrect username, such as "USERXXX," I received a message stating that the user was not in the cp directory, but there was no crash. However, when I used a correct username, such as "MAINT620," the crash/IPL occurred.

  1. May we presume then that the version of z/VM you are using is z/VM 6.2? Have you tried a newer version, such as 7.1 or 7.2 or 7.3? Does the same problem occur with them?

Yes, it is 6.2 and it does occur with the others the same way

  1. May we see your complete Hercules logfile please?  (for a test run without a OSTAILOR QUIET statement in it!!) (Or with it changed to OSTAILOR VM instead!!) *`()`**
  1. From the description of the error, this sounds more like a z/VM bug than a Hercules bug, since z/VM is the one that is crashing, not Hercules. That is to say, based on the description of the problem, I can't see how Hercules could possibly be causing this problem. It's not going to do anything different when one userid is used as opposed to another. It's going to do the exact same thing. So the problem (bug) is obviously in z/VM and not Hercules.

Indeed, it looked to me line an "orderly" crash. Being a z/VM bug it might mean that people could bring down a physical machine by just submitting one of these "malformed" cards it seems.

*`()** _I wish people would **stop** using **ostailor quiet**!!  Especially when reporting problems!!  It hides things that might be important with respect to the problem being reported!!_  >:-(`

Not for problem reporting. Just for "production" as most of the extra debugging messages send Jason haywire.

MockbaTheBorg commented 1 year ago
  • z15.cnf.txt

FYI:  you don't need any of the FACILITY statements you have in your Hercules configuration file (except maybe 55, but I'm doubting you even need that one either). All of the facilities you are enabling are already enabled by default. Enter facility query all (or facility query long or facility query xxx, etc) for a list of recognized facilities and which are enabled by default and which are not. (see help facility for more information.)

Those are reminiscent of previous configuration. I will remove the ones active by default. I have been doing some configuration cleanup lately, thanks for the tip.

Fish-Git commented 1 year ago

*`()** _I wish people would **stop** using **ostailor quiet`**!!    . . ._

Not for problem reporting. Just for "production" as most of the extra debugging messages send Jason haywire.

Jason?! Well there's your problem! Jason was designed for Hercules 3.07! It's not compatible with Hercules 4.x, let alone any version of SDL Hercules Hyperion! Hell, it's not even a 64-bit program!

As far as I know, my HercGUI is the only Windows Hercules GUI that works properly with SDL Hercules Hyperion.

Jason certainly looks really cool. I was (and still am!) impressed with its user interface design when it first came out. Unfortunately though, it wasn't written (designed) too well as a maintainable product. It was written to use (call into) the low-level windows APIs directly, rather than written as a higher-level windows application utilizing a windows application framework, such as MFC like my HercGUI is, thus making it much harder to maintain (as reflected by its age; it was written in 2010, when Hercules version 3.07 was current, and hasn't been updated since then).

If you're going to be running SDL Hercules Hyperion 4.x, I strongly suggest you stick with my HercGUI. That's not a cheap attempt to publicize/advertise my product either. It's just a good sense recommendation. If you're only interested in running a 13 year old Hercules 3.07, then Jason is fine. But for modern SDL Hercules Hyperion 4.x, you should stick with HercGUI.

MockbaTheBorg commented 1 year ago

Oh don't worry about Jason in this case. I am not running it inside Jason while testing this issue.

I have also modified Jason to work nicely with Hercules Hyperion 4.x. That's working fine, but after I deployed HercPRT I have used it less often.

Fish-Git commented 1 year ago

FWIW, I was able to easily reproduce the problem using current git running z/VM 7.3.

I did not bother trying any other version of Hercules or any other version of z/VM, since I don't really see the need. I'm 99.9% sure this is a z/VM bug, not a Hercules bug.

Nevertheless, I am having a friend try it on his zPDT to confirm my suspicion. If it fails the same way on the zPDT, then that would clinch it with 100% certainty.

arfineman commented 1 year ago

Hi Fish, Can you try this on 4.21? I have a similar issue that works on 4.21, but fails on all subsequent releases. Best regards,

Fish-Git commented 1 year ago

Can you try this on 4.21? I have a similar issue that works on 4.21, but fails on all subsequent releases.

4.21? You mean Hercules version 4.2.1?

Yes, the same problem occurs with z/VM 7.1 using Hercules 4.2.1.

Fish-Git commented 1 year ago

  UPDATE  

Nevertheless, I am having a friend try it on his zPDT to confirm my suspicion. If it fails the same way on the zPDT, then that would clinch it with 100% certainty.

I was wrong.  :(

It's a Hercules bug.  :(

The exact same version of z/VM running on the zPDT works flawlessly. z/VM does NOT crash. It only crashes on Hercules.  :(

(SIGH!)

Debugging in progress...

Fish-Git commented 1 year ago

  UPDATE #2!!  

It's a bug in z/VM after all!!

Further testing on the zPDT has revealed this issue is actually a bug in z/VM! My friend was able to reliably reproduce it on his zPDT system. Our original test was flawed and failed to reproduce the crash.

But once we updated our testing procedure, BINGO!  The failure (z/VM "crash") occurred, just like it does on Hercules!

Apparently, IBM's zPDT emulator has special logic (special handling) in its awsrdr device handler that pre-validates ID (or USERID) cards and does something special to prevent z/VM from crashing whenever an invalid ID card is detected. However, this special handling logic seems to only be executed when the card deck being submitted is in ASCII format as opposed to EBCDIC format.

When the card deck is submitted in EBCDIC format however (which bypasses the zPDT special handling logic), z/VM on the zPDT crashes just like it does with Hercules:

HCPDMP908I SYSTEM FAILURE ON CPU 0000, CODE - LAL008

Hercules of course, does not contain any type of special ID card handling. It just feeds the submitted card deck to z/VM as-is (after translating it to EBCDIC of course), which leads to the z/VM crash whenever the ID card is invalid (malformed). The exact same thing occurs on the zPDT however, when the deck being submitted is already in EBCDIC format (but not when it's in ASCII format).

Now all I have to do is figure out how to report this bug to IBM. Or decide whether we should even bother to report this to IBM.

IN ANY CASE, the incorrect behavior originally reported by @MockbaTheBorg is not -- repeat: NOT -- a Hercules bug. It is a z/VM bug.

I am closing this issue as "Invalid" and "Won't fix".