binfmt for mach-o executables? about orbstack HOT 12 CLOSED

Thanks for those commands! I gave this a quick shot last month and it didn't work so I put it on the backburner (probably typo in the magic or mask), but your commands seem to work.

There are some kinks to work out for proper support, but this is a good start.

from orbstack.

It is possible to run mach-o via binfmt:

# for mach-o universal binary (all fields in universal header are big endian)
sudo /usr/sbin/update-binfmts --install mac-binfmt-universal /opt/orbstack-guest/bin/mac \
    --magic "\xca\xfe\xba\xbe\x00\x00\x00\x02\x01\x00\x00\x07" \
    --mask  "\xff\xff\xff\xff\x00\x00\x00\x00\xff\xff\xff\x00" \
    --credentials yes --preserve no --fix-binary yes

# for mach-o single architecture binary (little endian)
sudo /usr/sbin/update-binfmts --install mac-binfmt-nonuniversal /opt/orbstack-guest/bin/mac \
    --magic "\xcf\xfa\xed\xfe\x0c\x00\x00\x01" \
    --mask  "\xff\xff\xff\xff\x00\xff\xff\xff" \
    --credentials yes --preserve no --fix-binary yes

reference: https://en.wikipedia.org/wiki/Mach-O

from orbstack.

Already implemented at /mnt/machines.

from orbstack.

Released in v0.7.0.

from orbstack.

Thanks for those commands! I gave this a quick shot last month and it didn't work so I put it on the backburner (probably typo in the magic or mask), but your commands seem to work.

There are some kinks to work out for proper support, but this is a good start.

Thank you for the explanation, I am really hoping to see official support for this.
I would say OrbStack is the best "macOS subsystem for Linux" I've ever seen. 👍

from orbstack.

@imkiva @SEmmmer @XingjianXie Can I get your opinion on how to handle argument/path translation for binfmt?

Currently, prefixing commands with mac and linking with mac link will conservatively translate some paths based on some heuristics to avoid mangling arguments, while specifying -p will translate all paths. Path translation works by resolving paths as viewed from the Linux perspective to the equivalent Mac path. So for example (Linux = macOS path):

• /home/user = /Users/user/OrbStack/machine/home/user
• /Users/user = /Users/user
• /mnt/mac/Applications = /Applications

This makes running most commands much smoother, but it might be surprising behavior for arguments to be modified when running executables with binfmt. What do you think?

from orbstack.

from orbstack.

Yes, that's why I decided to only translate paths conservatively by default. Better to miss some paths than break others (e.g. remote ones) with no recourse.

I guess it probably makes sense to use the same logic for binfmt.

from orbstack.

This makes running most commands much smoother, but it might be surprising behavior for arguments to be modified when running executables with binfmt. What do you think?

It is good that an executable from macOS can directly access files within the orb. And I don't think translating the path argument will cause much confusion if it is documented. As we all know the orb Linux is located in a certain location in macOS, thus it is natural to have this mechanism.

A good question, as @XingjianXie mentioned, is how to tell a Linux path from macOS one, like, /usr/bin. This path exists both in macOS and Linux, and it is impossible to decide if it should be translated without the users' option.

Say, I have a program used as copy <a> <b> which copies all files in <a> to <b>. The problem arises when I type

# which argument should be translated?
copy /usr/bin /usr/local/bin

Maybe it is reasonable to have something like /mnt/linux: if a path is prefixed with /mnt/linux, we translate it to /Users/user/OrbStack/machine/. It's ugly but works well for edge cases. The above counterexample becomes:

copy /mnt/linux/usr/bin /usr/local/bin

from orbstack.

Good idea! /mnt/linux could be a symlink to / to make this explicit.

from orbstack.

And maybe another idea: symbolically link other distros in orb to /mnt/<distro>, but I don't know if it is useful (maybe no).

from orbstack.

Added for the next version.

from orbstack.