-
-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ModeSelect6 fails with DEC Alpha system #1402
Comments
Digging through the code (and adding more log messages) reveals that ModeSelect6 is called with a page code of 0 (== "supported diagnostic pages") but the code in |
Thanks for reporting, and tracking down the code that’s responsible. The next step here would be to track down what the SCSI specification says about ModeSelect6 page code 0. We don’t have an active core developer in this project right now, so if you’re up for it we would very much welcome your contribution. |
Additionally, it would be helpful if you could test with the previous stable release version, April 2023. There was a good amount of refactoring that happened, which also touched the ModeSelect code. |
v23.04.01 shows the same behaviour. Digging deeper now and trying to come up with a PR 🤞🏻 |
So turns out it was actually three bugs, one generic, two specific to DEC Alpha, in ModeSelect6 😆 |
Merged. Thanks for the patches! |
Follow-up on PiSCSI#1402, PiSCSI#1405, PiSCSI#1427 This is the first (yet incomplete) test to cover this behavior. Signed-off-by: Klaus Kämpf <kkaempf@gmail.com>
Follow up on PiSCSI#1402, PiSCSI#1405 which had a full test case missing. Signed-off-by: Klaus Kämpf <kkaempf@gmail.com>
OpenVMS Alpha sends a strange ModeSelect payload, apparently one byte too large. This was 'fixed' by a (wrong) length calculation in PiSCSI#1405, breaking PiSCSI#1427. This PR - fixes the wrong length calculation - improves the loop test in scsi_command_util::ModeSelect to prevent a buffer overflow. (Remaining length was checked for > 0, but buffer access is at offset and offset + 1, effectively requiring 2 bytes.) - the loop test fix makes PiSCSI#1402 pass - adds a testcase for PiSCSI#1402 - adds a testcase for PiSCSI#1427 Fixes issue PiSCSI#1427 Signed-off-by: Klaus Kämpf <kkaempf@gmail.com>
* Allow 'empty' ModeSelect6 tl;dr Treat a computed length of 0 as `has_valid_page_code`. Details: The SRM console (aka 'BIOS') of DEC Alpha sends an empty ModeSelect6 with the following data: ~~~ ModeSelect6, CDB $151000000c00 ~~~ That makes 12 byte(s) as follows ~~~ 0 1 2 3 4 5 6 7 8 9 10 11 00 00 00 08 00 00 00 00 00 00 02 00 ~~~ decoding it (accoring to [1], Section 8.3.3, Table 94) gives us Mode Data Length 0 Medium Type 0 Device-specific 0 Block desc len 8 Density Code 0 Number of blks 0 Reserved 0 Block length 512 `scsi_command_util::ModeSelect` computes ~~~ offset = 4 + buf[3]; ~~~ giving 12 and ~~~ length -= offset; ~~~ giving 0. Thus it never enters the `while` loop and `has_valid_page_code` stays `false`, raising an error. [1] [Small Computer System Interface - 2 rev 10L.pdf](https://dn790004.ca.archive.org/0/items/SCSISpecificationDocumentsSCSIDocuments/Small%20Computer%20System%20Interface%20-%202%20rev%2010L.pdf) Signed-off-by: Klaus Kämpf <kkaempf@gmail.com> * Allow ModeSelect with page code 1 OpenVMS Alpha (the operating system, not the SRM BIOS) uses ModeSelect6 with a page code of 1. The semantics are unknown, just accepting it works for me. Signed-off-by: Klaus Kämpf <kkaempf@gmail.com> * Fix page length computation in ModeSelect tl;dr The 'skip to next ModeSelect page' computation was off-by-one, either not taking the page code itself into account or missing the fact that the page length is given as `n - 1`. Fix: Add 1 to the computed length. Details: OpenVMS Alpha sends a ModeSelect6 as follows ~~~ command: ModeSelect6, CDB $151000001900 payload: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 00 00 00 08 00 00 00 00 00 00 02 00 01 0a 24 00 00 00 00 00 00 00 00 00 00 ~~~ This translates to (accoring to [1], Section 8.3.3) ~~~ Mode Data Length 0 Medium Type 0 Device-specific 0 Block desc len 8 ~~~ with the following offset / length computation _before_ the `while` loop ~~~ offset = 12 length = 13 ~~~ The first payload section is ~~~ 4 5 6 7 8 9 10 11 00 00 00 00 00 00 02 00 ~~~ translating to ~~~ Density Code 0 Number of blks 0 Reserved 0 Block length 0x200 512 ~~~ Then follows a pagecode 1 as ~~~ 12 13 14 15 16 17 18 19 20 21 22 23 24 01 0a 24 00 00 00 00 00 00 00 00 00 00 ~~~ translating to ~~~~ Page code 1 Page length -1 10 Mode parameters 24 00 00 00 00 00 00 00 00 00 00 ~~~ computing (inside the `while` loop, as `// Advance to the next page`) ~~~ size = 10 + 2 = 12 ~~~ followed by new `offset` and `length` values ~~~ offset = 25 length = 1 ~~~ So it stays in the `while` loop (and has a larger-than-buffer `offset` value) Signed-off-by: Klaus Kämpf <kkaempf@gmail.com> Fix length calculation in scsi_command_util::ModeSelect OpenVMS Alpha sends a strange ModeSelect payload, apparently one byte too large. This was 'fixed' by a (wrong) length calculation in PiSCSI#1405, breaking PiSCSI#1427. This PR - fixes the wrong length calculation - improves the loop test in scsi_command_util::ModeSelect to prevent a buffer overflow. (Remaining length was checked for > 0, but buffer access is at offset and offset + 1, effectively requiring 2 bytes.) - the loop test fix makes PiSCSI#1402 pass - adds a testcase for PiSCSI#1402 - adds a testcase for PiSCSI#1427 Fixes issue PiSCSI#1427 Signed-off-by: Klaus Kämpf <kkaempf@gmail.com> Improve buffer overflow checking in scsi_command_util::ModeSelect Signed-off-by: Klaus Kämpf <kkaempf@gmail.com>
OpenVMS Alpha sends a strange ModeSelect payload, apparently one byte too large. This was 'fixed' by a (wrong) length calculation in PiSCSI#1405, breaking PiSCSI#1427. This PR - fixes the wrong length calculation - improves the loop test in scsi_command_util::ModeSelect to prevent a buffer overflow. (Remaining length was checked for > 0, but buffer access is at offset and offset + 1, effectively requiring 2 bytes.) - the loop test fix makes PiSCSI#1402 pass - adds a testcase for PiSCSI#1402 - adds a testcase for PiSCSI#1427 Fixes issue PiSCSI#1427 Signed-off-by: Klaus Kämpf <kkaempf@gmail.com>
Follow up on PiSCSI#1402, PiSCSI#1405 which had a full test case missing. Signed-off-by: Klaus Kämpf <kkaempf@gmail.com>
Info
Describe the issue
Booting from piscsi fails in the SRM console (aka 'BIOS') with
failed to open
Running with debug reveals
The text was updated successfully, but these errors were encountered: