4 ms·

Does that mean part of the compiler is security-critical?

by trasz 5y ago

skissane 5y ago
Essentially, yes, it does. Classic AS/400 software runs all programs, belonging to all users, in a single address space. The security boundary between different programs/users is enforced at the bytecode level, not at the machine code level, so the bytecode-to-machine code translator is security-critical. That translator is a core part of the OS, whereas the compiler frontends, while shipped with the OS, are not so core. However, I believe the current version of the translator code was actually extracted out of IBM's standard compiler backend for other platforms. And while this security is primarily software-based, it is partially hardware-accelerated – POWER has a tagged memory extension which gives you one tag bit for every 16 bytes of memory, and 400/i uses that tag bit to help detect (intentional or accidental) pointer forgery. It is worth noting that this is only a performance optimisation, it provides very little security in itself – the instructions to set the tag bit are (from the hardware viewpoint) unprivileged, so if you have the ability to execute arbitrary machine code, you can forge pointers to your heart's content. But the translator will not generate those tag-setting instructions for you, to do that you need to actually generate POWER machine code yourself – and there is no unprivileged interface which lets you run arbitrary machine code in the single address space. By contrast, newer stuff on 400/i runs in separate address spaces (teraspaces), including recent versions of Java and the Unix compatibility subsystem (PASE). So a Python script, for example, since Python usually runs under PASE, it uses the same address space per process security model which is used on Unix(-like) systems. (There is actually an old port of Python 2.7, called iSeriesPython, which runs Python inside the classic AS/400 environment ILE instead of the Unix compatibility PASE environment; even that I believe is still running it inside a separate address space aka teraspace for performance reasons, but probably would run fine inside the single address space instead; that whole approach to porting Python to IBM i has been abandoned, because it has few advantages over the PASE approach, but PASE makes the porting work a lot easier.)
- zozbot234 5y ago
  > The security boundary between different programs/users is enforced at the bytecode level, not at the machine code level, so the bytecode-to-machine code translator is security-critical. Worth noting that this is exactly how sandboxing across WASM modules works nowadays. It's not exotic technology.
  - pjmlp 5y ago
    Indeed, WebAssembly tries to sell themselves as exotic and having discovered the magic bytecode, while all these ideas go back to early 1960's. Burroughs is another architecture with lots of similar ideas, still being sold nowadays by Unisys.
- trasz 5y ago
  Thanks! Do you know why IBM did it this way, as opposed to implementing the security part fully in hardware? Or perhaps do you have some pointers or keywords I could use to search for?
  - sillywalk 5y ago
    I believe because the original AS/400 hardware used a proprietary CPU (Called IPMI ?) and proprietary RAM that had extra space for tag bits. When the AS/400 was moved to POWER processors, IBM added extensions for OS/400 called PowerPC AS[0], and uses some "magic" to store a tag bit in the ECC bits of standard RAM. Also, "Fortress Rochester" by Frank Soltis (the follow up to Inside the AS/400) gives a detailed look at the differences compared to other systems. [0] https://www.devever.net/~hl/ppcas https://www.devever.net/~hl/ppcas
    - skissane 5y ago
      > I believe because the original AS/400 hardware used a proprietary CPU (Called IPMI ?) Called IMPI (Internal MicroProgrammed Interface), the CPU architecture used by the CISC AS/400’s was the same as that used by the earlier System/38. Documented in this manual: http://bitsavers.org/pdf/ibm/system38/SC21-9037-3_IBM_System_38_Internal_Microprogramming_Instructions_Formats_and_Functions_Reference_4th_ed_198508.pdf http://bitsavers.org/pdf/ibm/system38/SC21-9037-3_IBM_System... With AS/400, IBM stopped publicly so documenting these kinds of details, but most of that manual still applies to CISC AS/400. And, I believe IBM included a disassembler in the diagnostic tools shipped with the OS, which I assume would have known about any new instructions, so it would be possible (with sufficient effort) to work out what the changes in CISC AS/400 were. The IMPI instruction set has some resemblances to the IBM 370 mainframe instruction set, but is not compatible with it.
ch_123 5y ago
The compilers generate MI instructions. The translation to real PowerPC machine code is a separate process which happens in a part of the SLIC (effectively the kernel). The machine code of an executable is not accessible by users (even privileged ones) so it's not possible to patch a binary with your own instructions.
- skissane 5y ago
  > The machine code of an executable is not accessible by users (even privileged ones) so it's not possible to patch a binary with your own instructions. I’m not so convinced this is true. If you have access to SST, you can use the Display/Alter/Dump tool to make arbitrary changes to memory. A common use of this is to put your program object into system state so it can use system domain APIs or MI instructions even when the system is at security level 40 or above. Are you sure there is no way using SST to either alter the memory containing POWER machine code, or give a program you wrote authority to do that?
  - ch_123 5y ago
    That is probably true. Perhaps I should have said "If you are able to patch the machine code in a program object, you probably have full access to the system anyway".
    - skissane 5y ago
      Definitely you can use SST to modify the translated POWER machine code. Here is an article giving an example of why you might want to do it, and how to do it: https://www.mcpressonline.com/programming/rpg/change-the-last-used-date-of-an-ibm-i-system-object-arbitrarily https://www.mcpressonline.com/programming/rpg/change-the-las... Of course unprivileged users can’t do this. But if you have privilege to access SST (which means you basically have the equivalent of root in Unix) you can do absolutely anything if you know how.

Does that mean part of the compiler is security-critical?

by trasz 5y ago

Does that mean part of the compiler is security-critical?

Essentially, yes, it does. Classic AS/400 software runs all programs, belonging to all users, in a single address space. The security boundary between different programs/users is enforced at the bytecode level, not at the machine code level, so the bytecode-to-machine code translator is security-critical. That translator is a core part of the OS, whereas the compiler frontends, while shipped with the OS, are not so core. However, I believe the current version of the translator code was actually extracted out of IBM's standard compiler backend for other platforms. And while this security is primarily software-based, it is partially hardware-accelerated – POWER has a tagged memory extension which gives you one tag bit for every 16 bytes of memory, and 400/i uses that tag bit to help detect (intentional or accidental) pointer forgery. It is worth noting that this is only a performance optimisation, it provides very little security in itself – the instructions to set the tag bit are (from the hardware viewpoint) unprivileged, so if you have the ability to execute arbitrary machine code, you can forge pointers to your heart's content. But the translator will not generate those tag-setting instructions for you, to do that you need to actually generate POWER machine code yourself – and there is no unprivileged interface which lets you run arbitrary machine code in the single address space. By contrast, newer stuff on 400/i runs in separate address spaces (teraspaces), including recent versions of Java and the Unix compatibility subsystem (PASE). So a Python script, for example, since Python usually runs under PASE, it uses the same address space per process security model which is used on Unix(-like) systems. (There is actually an old port of Python 2.7, called iSeriesPython, which runs Python inside the classic AS/400 environment ILE instead of the Unix compatibility PASE environment; even that I believe is still running it inside a separate address space aka teraspace for performance reasons, but probably would run fine inside the single address space instead; that whole approach to porting Python to IBM i has been abandoned, because it has few advantages over the PASE approach, but PASE makes the porting work a lot easier.)

zozbot234 5y ago
> The security boundary between different programs/users is enforced at the bytecode level, not at the machine code level, so the bytecode-to-machine code translator is security-critical. Worth noting that this is exactly how sandboxing across WASM modules works nowadays. It's not exotic technology.
- pjmlp 5y ago
  Indeed, WebAssembly tries to sell themselves as exotic and having discovered the magic bytecode, while all these ideas go back to early 1960's. Burroughs is another architecture with lots of similar ideas, still being sold nowadays by Unisys.
trasz 5y ago
Thanks! Do you know why IBM did it this way, as opposed to implementing the security part fully in hardware? Or perhaps do you have some pointers or keywords I could use to search for?
- sillywalk 5y ago
  I believe because the original AS/400 hardware used a proprietary CPU (Called IPMI ?) and proprietary RAM that had extra space for tag bits. When the AS/400 was moved to POWER processors, IBM added extensions for OS/400 called PowerPC AS[0], and uses some "magic" to store a tag bit in the ECC bits of standard RAM. Also, "Fortress Rochester" by Frank Soltis (the follow up to Inside the AS/400) gives a detailed look at the differences compared to other systems. [0] https://www.devever.net/~hl/ppcas https://www.devever.net/~hl/ppcas
  - skissane 5y ago
    > I believe because the original AS/400 hardware used a proprietary CPU (Called IPMI ?) Called IMPI (Internal MicroProgrammed Interface), the CPU architecture used by the CISC AS/400’s was the same as that used by the earlier System/38. Documented in this manual: http://bitsavers.org/pdf/ibm/system38/SC21-9037-3_IBM_System_38_Internal_Microprogramming_Instructions_Formats_and_Functions_Reference_4th_ed_198508.pdf http://bitsavers.org/pdf/ibm/system38/SC21-9037-3_IBM_System... With AS/400, IBM stopped publicly so documenting these kinds of details, but most of that manual still applies to CISC AS/400. And, I believe IBM included a disassembler in the diagnostic tools shipped with the OS, which I assume would have known about any new instructions, so it would be possible (with sufficient effort) to work out what the changes in CISC AS/400 were. The IMPI instruction set has some resemblances to the IBM 370 mainframe instruction set, but is not compatible with it.

ch_123 5y ago

The compilers generate MI instructions. The translation to real PowerPC machine code is a separate process which happens in a part of the SLIC (effectively the kernel). The machine code of an executable is not accessible by users (even privileged ones) so it's not possible to patch a binary with your own instructions.

skissane 5y ago
> The machine code of an executable is not accessible by users (even privileged ones) so it's not possible to patch a binary with your own instructions. I’m not so convinced this is true. If you have access to SST, you can use the Display/Alter/Dump tool to make arbitrary changes to memory. A common use of this is to put your program object into system state so it can use system domain APIs or MI instructions even when the system is at security level 40 or above. Are you sure there is no way using SST to either alter the memory containing POWER machine code, or give a program you wrote authority to do that?
- ch_123 5y ago
  That is probably true. Perhaps I should have said "If you are able to patch the machine code in a program object, you probably have full access to the system anyway".
  - skissane 5y ago
    Definitely you can use SST to modify the translated POWER machine code. Here is an article giving an example of why you might want to do it, and how to do it: https://www.mcpressonline.com/programming/rpg/change-the-last-used-date-of-an-ibm-i-system-object-arbitrarily https://www.mcpressonline.com/programming/rpg/change-the-las... Of course unprivileged users can’t do this. But if you have privilege to access SST (which means you basically have the equivalent of root in Unix) you can do absolutely anything if you know how.