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?

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.

https://github.com/openbsd/src/commit/312e26c80be876012ae979...

The ports tree is being cleansed of syscall(2) usage, until they're all gone.

msyscall, pinsyscall, recent mandatory IBT/BTI, xonly. OpenBSD is making some waves, but people aren't really seeing them yet.

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.

https://marc.info/?l=openbsd-cvs&m=168254711511764&w=2

E.g: https://marc.info/?l=openbsd-cvs&m=167337396024167&w=2

All of those are examples of privilege seperated software imported from OpenBSD, pf and thus pflogd(8), dhclient(8) and yplapd(8).

https://www.openbsd.org/innovations.html

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.

Dragos Ruiu (@dragosr) also provided the video recording on his Twitter account.

https://twitter.com/dragosr/status/1639015014177841153

OpenSSH developers documented some issues they found with PAM, in implementation and design.

https://www.dtucker.net/pam/

BSD Authentication is much nicer, but has only been adopted by OpenBSD.

https://man.openbsd.org/authenticate.3

https://man.openbsd.org/auth_subr.3

Additional context, and status about recent developments in OpenBSD.

BROP: https://www.scs.stanford.edu/brop/ (paper "Hacking Blind" (2014): https://www.scs.stanford.edu/brop/bittau-brop.pdf

xonly mitigation status: https://marc.info/?l=openbsd-tech&m=167501519712725&w=2

I will agree that you have chosen your words carefully, and with obvious intent.

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

If you look at the mitigations OpenBSD is doing as attack surface reduction, it means ultimately fewer tools in the attackers toolbox.

It seems many of you are missing the forest for the trees.

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

https://man.openbsd.org/pledge#prot_exec

Perhaps you should spend more than 5 minutes reading about OpenBSD's layers of mitigations.

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.

https://man.openbsd.org/qcgpio

https://man.openbsd.org/qciic

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.

https://github.com/openbsd/src/commit/74edc71ccae4051eda11fa...

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.

The upstreamed Qualcomm drivers in the Linux kernel require a device tree from the vendor which doesn't exist yet for this machine, I believe the Linux community has something cobbled together for the ThinkPad x13s, or got something from Lenovo.

> Oh, it's because of "APCI" mode working with openbsd apparently...

Indeed, OpenBSD attempts to support these machines to some extent in ACPI mode, but from what I read the ACPI tables are in bad shape/incomplete. "Good enough for Windows, ship it.".

The recently released OpenBSD 7.2 boots and installs on it, support for the same Qualcomm Snapdragon SoC used in the ThinkPad x13s was added during last release cycle, so support for the Microsoft Dev Kit 2023 came for the most part for free.

https://www.openbsd.org/72.html

OpenBSD developer Patrick Wildt shared boot messages (dmesg) here: https://twitter.com/bluerise/status/1585584481854816256

Another UK tech reviewer Alex Ellis showed it booting OpenBSD into X11: https://blog.alexellis.io/linux-on-microsoft-dev-kit-2023/

This talk was given at this years EuroBSDcon in Vienna, recording is up on YouTube.

https://2022.eurobsdcon.org/

https://www.youtube.com/watch?v=36qZYL5RlgY

Some really great talks this year from all the *BSDs, highly recommend checking a look: https://www.youtube.com/playlist?list=PLskKNopggjc6_N7kpccFZ...

That's what BitPay handles. The OpenBSD Foundation doesn't hold onto any Bitcoin, it's immediately converted into USD.

Not at all.

It's not the broadest permissions from the parent, but the promises at the time of the fork, for example you can setup the parent in such a way that you fork off early a unprivileged (or privileged) child that has a different set of promises from the parent.

No, simply because using unveil is not mandatory. It's opt-in. The filesystem becomes "veiled" to the application only after the first call to unveil(), subsequent calls "unveil" files/directories until the final call which locks it, preventing any future unveils.

pledge(2)'s predecessor used bits, it was inflexible: https://flak.tedunangst.com/post/string-interfaces

The idea of a "pledge" utility isn't a novel one, it is my understanding that one was intentionally not provided.

> I'll definitely be doing more to make the C API as compatible with OpenBSD as possible.

One suggestion I might add, it would be worth trying to compile any of OpenBSD's privilege separated network daemons on Linux (w/ Cosmopolitan Libc, or others). While you may have intended to use this facility primarily for your own APE Binaries, I suspect you'll find that the despite your intentions to make this compatible with the C API definition of pledge(2), in practice, your implementation is incompatible with privsep/privdrop software, for which pledge was designed. It was never intended for application "sandboxing".