> I will say, though, that single VCPU guests would not have met our immediate needs in the Oxide product!
Could Oxide not have helped push multi-vcpu guests out the door by sponsoring one of the main developers working on it, or contributing to development? From a secure design perspective, OpenBSD's vmd is a lot more appealing than bhyve is today.
I saw recently that AMD SEV (Secure Encrypted Virtualization) was added, which seems compelling for Oxide's AMD based platform. Has Oxide added support for that to their bhyve fork yet?
> Could Oxide not have helped push multi-vcpu guests out the door by sponsoring one of the main developers working on it, or contributing to development?
Being that vmd's values are aligned with OpenBSD's (security above all else), it is probably not a good fit for what Oxide is trying to achieve. Last I looked at vmd (circa 2019), it was doing essentially all device emulation in userspace. While it makes total sense to keep as much logic as possible out of ring-0 (again, emphasis on security), doing so comes with some substantial performance costs. Heavily used devices, such as the APIC, will incur pretty significant overhead if the emulation requires round trips out to userspace on top of the cost of VM exits.
> I saw recently that AMD SEV (Secure Encrypted Virtualization) was added, which seems compelling for Oxide's AMD based platform. Has Oxide added support for that to their bhyve fork yet?
SEV complicates things like the ability to live-migrate guests between systems.
OpenBSD developers are making a serious effort to kill off indirect syscalls, the base system is completely clean, take a look at the work Andrew Fresh did to adapt Perl. He wrote a complete syscall "dispatcher" or emulator for the Perl syscall function so that it calls the libc stubs.
OpenBSD disables jump tables in Clang on amd64 due to IBT, some architectures also had jump tables disabled as part of the switch to --execute-only ("xonly") binaries by default, e.g: powerpc64/sparc64/hppa.
Won't help you with Docker containers, but OpenBSD/arm64 will run OOTB on the MS Dev Kit, NVMe works, USB-3 works, 2.5Gbe Realtek NIC is supported by the ure(4) driver. The ath11k wireless is not supported though, so you'll need a USB adapter for that unfortunately.
If you're looking for a free Unix-y environment to play with, with >11000 binaries packages available.
You need to use the mini-DisplayPort for video output, not Type-C. This is a UEFI limitation on the machine.
OpenBSD begrudgingly made an exception for LLVM/Clang, after vocal opposition to the re-licencing. It currently uses LLVM/Clang 13 and has been making progress towards 15. Licensing is not the problem here. Most of the sanitizers are simply not enabled in the version shipped in base, and require runtime libraries that have not been ported to OpenBSD.
Valgrind exists in ports, but it is ancient and broken. It does not play well with various security mitigations.
> OpenBSD begrudgingly made an exception for LLVM/Clang […] Licensing is not the problem here
If it isn’t a problem, why do you say “begrudgingly”?
I think they are pragmatic but also do find it a problem. Why else would they say “source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD”?
I didn't say it wasn't a problem. I said it was not the problem here. Important distinction.
Licensing is not the reason for the sanitizers not being enabled in the default build, a lot of stuff isn't. If it were supported, it would probably be delegated to the ports version, along with the analyzer, additional llvm tools, cross-compiling, etc.
Are you asking why doesn't it execv(2) addr2line deep within the libc malloc implementation? Because calling execv(2) within libraries is frowned upon.. ;-)
The leak report is being generated internally by malloc. It is then logged via utrace(2) when a process is traced through ktrace(1).
The kdump utility simply dumps the report, strvis(3) escaping any potentially unsafe characters. As this is untrusted user data, passing it as the input/args to another command is unwise. Also kdump(1) uses pledge(2) and cannot execute commands.
I guess I’m confused what’s printing the output here. On other OSes typically things like this are implemented by malloc recording the addresses and whatever parses the report later doing the symbolication when displaying it. I guess kdump just dumps the report but is there no porcelain that takes the kdump data and cleans it up a bit more for human consumption?
You are arguing for a worse UX because of an arbitrary reason. Just link against the code in addr2line. Providing a good UX should always be in scope for a project.
Could Oxide not have helped push multi-vcpu guests out the door by sponsoring one of the main developers working on it, or contributing to development? From a secure design perspective, OpenBSD's vmd is a lot more appealing than bhyve is today.
I saw recently that AMD SEV (Secure Encrypted Virtualization) was added, which seems compelling for Oxide's AMD based platform. Has Oxide added support for that to their bhyve fork yet?