Initial support for OpenBSD 7.5

[shym]

This PR is a WIP as tests are failing but it makes at least the build succeed on OpenBSD 7.5.
Credits to @dustanddreams for identifying the breaking changes.

All the tests errors I see now are:

ld.lld: error: relocation refers to a symbol in a discarded section: __retguard_546
>>> defined in /home/build/solo5/toolchain/bin/../lib/x86_64-solo5-none-static/solo5_hvt.o

or similar with solo5_stub.o.

I think I’ve read somewhere similar errors being tackled previously. Any idea for a fix?

[adamsteen]

I did the initial port, I expect the ‘ret_guard’ protections need to be turned off in the linker or compiler, I don’t have the time to look too deeply atm, but will have a read over the next week to see what I find

[adamsteen]

Just read clang-local

clang includes the retguard security feature on amd64, arm64, mips64, powerpc and powerpc64. This feature can be disabled with the -fno-ret-protector or -fno-stack-protector options.

Should be enough to add -fno-ret-protector to ‘configure.sh’, oops look like we already do https://github.com/Solo5/solo5/blob/master/configure.sh#L438

sorry not sure, seems like something in the chain does not have -fno-ret-protector, that’s where I would look

or is the linker script (object definition thing) dropping the section OpenBSD needs? Sorry I am not more help

[hannesm]

What is the status of this PR? Also, is there any update with OpenBSD 7.6 now released?

[shym]

I had no time to make any progress on that work.
(I imagine the changes in that PR will be required anyway even if they are not enough.)

[omegametabroccolo]

I got solo5 to build + tests to pass on OpenBSD-current. On top of the changes proposed in this PR I:

• removed uses of vrp_continue and vrp_irq in tenders/hvt/hvt_openbsd_x86_64.c, since they were removed from the struct vm_run_params data structure
• added --Wl,--no-execute-only to every target that does some linking in tests/Makefile.tests
• ran configure.sh with TARGET_OBJCOPY=llvm-objcopy, which comes with the base OpenBSD install

After that, gmake runs smoothly. I don't know how you'd want to integrate these changes, but feel free to ask me anything.

Edit: Still on OpenBSD-current, pinning solo5 to my fork in opam gives a successful build, I can even build some examples from mirage-skeleton, but the resulting binaries enter a boot loop when launched.

[dinosaure]

but the resulting binaries enter a boot loop when launched.

Does this mean that your series of patches are not working? We would be very interested in closing this pull request and continuing support for OpenBSD.

[omegametabroccolo]

Does this mean that your series of patches are not working?

Now they are: the "boot loop" was due to vmm not updating the instruction pointer after doing I/O, as vmd does. Now examples from mirage-skeleton work fine:

$ cd mirage-skeleton/tutorial/noop
$ mirage configure -t hvt
Successfully configured the unikernel. Now run 'make' (or more fine-grained steps: 'make all', 'make depends', or 'make lock').
$ gmake depends
[...]
$ gmake build
[...]
$ doas solo5-hvt dist/noop.hvt
            |      ___|
  __|  _ \  |  _ \ __ \
\__ \ (   | | (   |  ) |
____/\___/ _|\___/____/
Solo5: Bindings version 496770f
Solo5: Memory map: 512 MB addressable:
Solo5:   reserved @ (0x0 - 0xfffff)
Solo5:       text @ (0x100000 - 0x236fff)
Solo5:     rodata @ (0x237000 - 0x27dfff)
Solo5:       data @ (0x27e000 - 0x336fff)
Solo5:       heap >= 0x337000 < stack < 0x20000000
Solo5: solo5_exit(0) called

[adamsteen]

It's great to see OpenBSD working again! I wish you well with the rest of the Mirage ecosystem.

[omegametabroccolo]

Should I maybe open a new pull request? I'm not very familiar with how things are done on github.

[dinosaure]

Should I maybe open a new pull request? I'm not very familiar with how things are done on github.

Yes, a new pull-request will be good for us. Thanks!