4 ms·

As awesome as these are, they're not really portable executables if you can't set their setuid bits and expect them to run as root like with normal executables,

As awesome as these are, they're not really portable executables if you can't set their setuid bits and expect them to run as root like with normal executables, right?

jart 3y ago
There's a program that's part of cosmos called `assimilate` which can turn any APE binary into a platform-specific binary. jart@nightmare:~$ /opt/cosmos/bin/assimilate --help assimilate: illegal option -- - actually portable executable assimilate v1.6 copyright 2023 justine alexandra roberts tunney usage: assimilate [-xapembfchv] [-o PATH] FILE... -h show help -v show version -f ignore soft errors -b don't remove freebsd from elf os/abi -c clobber input path w/o making backup -e convert to elf regardless of host os -m convert to macho regardless of host os -x convert to amd64 regardless of host cpu -a convert to arm64 regardless of host cpu -p convert to ppc64 regardless of host cpu -o PATH write modified binary to different file If you aren't using binfmt_misc then you can also pass the `--assimilate` flag to your APE binary, to turn it into a native executable, without having to use the tool. It's baked into the shell script. Just use the `less` command on any APE file and read the shell script. Once assimilated, you're free to turn it into a setuid binary. We also have patches in flight for the Linux Kernel as well as BSDs, to make APE native. https://justine.lol/ape.patch https://justine.lol/ape.patch
- dataflow 3y ago
  Oh wow, that's very nice! Thanks for sharing!
- amluto 3y ago
  Wow, that’s some combination of awesome and horrifying. Is there an actual written spec somewhere describing how this works? What happens if the APE embeds an ELF header and something else? Or multiple ELF headers?
  - jart 3y ago
    See the comments in https://justine.lol/ape.patch https://justine.lol/ape.patch and at the bottom of https://github.com/jart/cosmopolitan/blob/3.0/tool/build/apelink.c https://github.com/jart/cosmopolitan/blob/3.0/tool/build/ape... and also https://github.com/jart/cosmopolitan/blob/3.0/ape/loader.c https://github.com/jart/cosmopolitan/blob/3.0/ape/loader.c has good information too. I'm planning to roll it all into a formal looking specification pdf sometime very soon. Feedback is welcome. As for your question, ELF headers are defined in the APE shell script as printf 'octal' statements. The loader parses those out in order and looks to see if the e_machine matches the host architecture, and if so, uses that one.
    - amluto 3y ago
      I did read the comments. ISTM if this thing goes in the Linux kernel (and maybe a BSD kernel and maybe a Windows kernel, yeah right), it should at least be written down cleanly. It doesn’t necessarily need to be a PDF. (Linux can load ELF files. ELF has a spec or five that are only mostly horrible, and I’m not actually aware of a unified ELF spec that covers everything, but this isn’t really a showstopper.) Off the top of my head, it seems like it would be nice for whatever bit of the shell-compatible header encodes an ELF header to also indicate that it’s ELF (as opposed to something else) and maybe even that it’s Linux-flavored ELF. Maybe like: #ELF-Linux-LE print… #ELF-BSD-LE print… #ELF-U-boot-BE print… This isn’t intended to be a real proposal. Little- and big-endian in the same binary would be even more amusing than the average APE binary, and I don’t remember off the top of my head exactly which properties of the target can be unambiguously determined from the binary encoding of the ELF header. (And obviously there would be some shell-flavored conditions in the middle.)

As awesome as these are, they're not really portable executables if you can't set their setuid bits and expect them to run as root like with normal executables, right?

jart 3y ago

There's a program that's part of cosmos called `assimilate` which can turn any APE binary into a platform-specific binary. jart@nightmare:~$ /opt/cosmos/bin/assimilate --help assimilate: illegal option -- - actually portable executable assimilate v1.6 copyright 2023 justine alexandra roberts tunney usage: assimilate [-xapembfchv] [-o PATH] FILE... -h show help -v show version -f ignore soft errors -b don't remove freebsd from elf os/abi -c clobber input path w/o making backup -e convert to elf regardless of host os -m convert to macho regardless of host os -x convert to amd64 regardless of host cpu -a convert to arm64 regardless of host cpu -p convert to ppc64 regardless of host cpu -o PATH write modified binary to different file If you aren't using binfmt_misc then you can also pass the `--assimilate` flag to your APE binary, to turn it into a native executable, without having to use the tool. It's baked into the shell script. Just use the `less` command on any APE file and read the shell script. Once assimilated, you're free to turn it into a setuid binary. We also have patches in flight for the Linux Kernel as well as BSDs, to make APE native. https://justine.lol/ape.patch https://justine.lol/ape.patch

dataflow 3y ago
Oh wow, that's very nice! Thanks for sharing!
amluto 3y ago
Wow, that’s some combination of awesome and horrifying. Is there an actual written spec somewhere describing how this works? What happens if the APE embeds an ELF header and something else? Or multiple ELF headers?
- jart 3y ago
  See the comments in https://justine.lol/ape.patch https://justine.lol/ape.patch and at the bottom of https://github.com/jart/cosmopolitan/blob/3.0/tool/build/apelink.c https://github.com/jart/cosmopolitan/blob/3.0/tool/build/ape... and also https://github.com/jart/cosmopolitan/blob/3.0/ape/loader.c https://github.com/jart/cosmopolitan/blob/3.0/ape/loader.c has good information too. I'm planning to roll it all into a formal looking specification pdf sometime very soon. Feedback is welcome. As for your question, ELF headers are defined in the APE shell script as printf 'octal' statements. The loader parses those out in order and looks to see if the e_machine matches the host architecture, and if so, uses that one.
  - amluto 3y ago
    I did read the comments. ISTM if this thing goes in the Linux kernel (and maybe a BSD kernel and maybe a Windows kernel, yeah right), it should at least be written down cleanly. It doesn’t necessarily need to be a PDF. (Linux can load ELF files. ELF has a spec or five that are only mostly horrible, and I’m not actually aware of a unified ELF spec that covers everything, but this isn’t really a showstopper.) Off the top of my head, it seems like it would be nice for whatever bit of the shell-compatible header encodes an ELF header to also indicate that it’s ELF (as opposed to something else) and maybe even that it’s Linux-flavored ELF. Maybe like: #ELF-Linux-LE print… #ELF-BSD-LE print… #ELF-U-boot-BE print… This isn’t intended to be a real proposal. Little- and big-endian in the same binary would be even more amusing than the average APE binary, and I don’t remember off the top of my head exactly which properties of the target can be unambiguously determined from the binary encoding of the ELF header. (And obviously there would be some shell-flavored conditions in the middle.)