> 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?
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.
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.
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.
> I'd argue that things like msyscall and mstack don't at all because they cost attackers only a couple of minutes of time once to develop a bypass technique (ie move the stack pointer before a syscall, reuse the authorized syscall instruction) that they can apply everywhere.
If you read up on library order randomization/re-link and retguard, you may find your technique won't be so reusable, even once you do manage to locate a syscall stub in libc.
> As others have mentioned as well using ROP to jump to the syscall instructions in libc with your own arguments (it’s not special…) bypasses restrictions in the current design.
...ignoring other mitigations.
> In fact I can extend it with something OpenBSD does not have a good implementation of yet, strong CFI, which would prevent jumping into the middle of a function to execute that syscall instruction. But there are more fundamental reasons why this doesn’t work.
Sounds like you need to spend 5 more minutes reading about retguard.
> But using it to prevent the introduction of new code is not all that effective, unless you are far more stringent about how you allow processes to allocate executable regions. For example, if you prevent a program from mapping in any new PROT_EXEC pages after it's initialized itself and then mimmutable all its code, then no new code can be introduced, which is a useful property. But you need that extra bit which mimmutable by itself doesn't give you.
You mean like pledge(2)? The vast majority of the base system is pledged. So programs without the prot_exec promise cannot make new PROT_EXEC mappings, or add it to any existing pages.
Apologies, I was pointing out the commit message itself rather than the contents of the commit, it's indeed full of magic numbers. It's reverse engineered, there are no docs from Qualcomm.
This is commit is plumbing work fixing GPIO support, which indirectly makes the keyboard work. I don't have any boot logs for the machine, but as I understand they have standard Microsoft-compatible HID keyboards/touchpads that work with OpenBSD's existing drivers.
Appreciate the additional context. It does seem like though a lot of magic is contained in the Qualcomm Windows drivers, with large parts of the ACPI tables being stubs or broken (requiring hardcoded driver quirks/workarounds).
I believe the Samsung Galaxy Book Go was tested with OpenBSD during the initial development for the ThinkPad x13s, keyboard support was added in this commit.
Many of these older generation "Windows on Snapdragon" laptops unfortunately did not use fast NVMe storage however, only slow eMMC and eUFS (Universal Flash Storage), the latter currently being unsupported by OpenBSD.
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?