notaplumber1

> 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?

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.

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.

I'm pretty sure parsing ELF binaries is out of scope for kdump(1), sorry, but I don't think that's going to happen.

It's not that difficult to run addr2line yourself with the information provided, and that's really for the best.

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.

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.