Bryan Steele @brynet@bsd.network

Not great timing, I know, but I'm thinking a Intel mini PC (e.g: N150, 11th Gen i5/i7) would work for my #OpenBSD testing & hacking, Any help towards this would be greatly appreciated. ​

https://www.paypal.com/donate/?hosted_button_id=ZQJC48GUPB3UU&source=url

https://www.amazon.ca/hz/wishlist/ls/2E7N6O3GTI6JF?sort=custom

#MutualAid #MutualAidRequests

I could use some help, friends. I'd really appreciate sharing. ​

If you can help out with the occasional pizza, that would really mean a lot to me. Monthly gifts would take care of a lot of my financial stress/anxiety as well.

https://brynet.ca/wallofpizza.html

https://www.paypal.com/donate/?hosted_button_id=ZQJC48GUPB3UU&source=url

Progress: $345 / $2500 CAD (monthly goal)

If you aren't able help with PayPal, I have an Amazon .ca wishlist with some odds & ends, computer hardware: https://www.amazon.ca/hz/wishlist/ls/2E7N6O3GTI6JF?sort=custom

(Native SegWit): bc1qzkchnc25yeqt9p24edsu5ln0mvh8hqdzdznlk2

If you find my shameless self boosts to be at all annoying, feel free to click on my profile, then the triple vertical dots next to my follow button, and finally "Hide boosts from @brynet

A early criticism heard of #OpenBSD pledge(2) was that the kernel contained a small number of hardcoded path checks in order to avoid the broader rpath promise. This meant some paths were implicitly readable by programs in order to satisfy the needs of libc.

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

OpenBSD is attempting to solve this by adding a new (non-public/non-exported*) __pledge_open(2) used by libc, which is like read-only open(2) whos file descriptors can not be written to, have attributes changed on them or passed with e.g: SCM_RIGHTS file descriptor passing.

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

* Recall that OpenBSD has system call origin verification and no indirect syscall access.

This is still a WIP, some parts remain uncommitted, but an interesting semantic change, which _should_ be mostly transparent for applications using pledge(2) already with rpath, those relying on the implicit paths may need to add filesystem related promises and use unveil(2). ​

#mutualaidrequest #mutualaid

I don't suppose that I have any #bsd #unix #foss #infosec friends out there willing to signal boost, by chance? ​ ​

https://bsd.network/@brynet/114458997143046937

It turns out a laptop based around a iphone chip is underwhelming, who'da thunk it.

The A18 Pro being similar to the M2, at least in theory, makes me somewhat optimistic that the Asahi team will work out the missing chicken bits and device tree support to m1n1.

The OpenBSD project, being based in Canada for the past 30 years, is not subject to California law.

Now stop fucking asking. ​

Note: Not speaking authoritatively on behalf of the project, yadda yadda.

Heads up: The recent pledge(2) "tmppath" removal has been backported to #OpenBSD 7.7/7.8, and includes updated base system utilities as well as new -stable packages for software using pledge(2), such as web browsers.

https://www.openbsd.org/errata78.html#p015_tmppath

https://www.openbsd.org/errata78.html#p016_pledge_sysctl

https://www.openbsd.org/errata78.html#p017_tmppath

https://www.openbsd.org/errata78.html#p018_pledgepaths

Don't forget to run pkg_add -u before applying the kernel syspatch/errata to avoid errors with old binaries on the new kernel.

If any of my past work on #OpenBSD, or my highlight posts here (or elsewhere) has been helpful, a small recurring monthly donation would be extremely appreciated. ​

https://brynet.ca/wallofpizza.html

https://bsd.network/@brynet/114458997143046937

​ .. I somehow even managed to find some time to review patches.

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

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

Goodbye pledge "tmppath", hello unveil("/tmp", "rwc")! ​

Some observant #OpenBSD users may have noticed developers removing the pledge(2) "tmppath" promise from all base utilities that were using it along with a handful of ports, because this promise, well.. it kinda sucks, and it predates a much better solution: unveil(2).

More info & some backstory in Theo de Raadt's commit.

deraadt@ modified src/{sys,lib}/*: pledge "tmppath" goes away because it sucks. The history is kind of
sad: unveil(2) was invented by Bob Beck and myself because a couple of us struggled and couldn't expand the "tmppath" mechanism to general use.
unveil(2) ended up being kind of "upside down" different, and so we never deleted "tmppath" because the refactorings seemed complicated.
However over the last two weeks, we're removed all the "tmppath" in base pretty easily, and the 18 ports using it have also been fixed.
The majority of situations now use unveil "/tmp" "rwc", unveil "/" "r" or similar, and then pledge "rpath wpath cpath", and this is generally needed to satisfy the mkstemp(3) family of functions in libc.
Use of "tmppath" will now cause pledge(2) to return EINVAL. There is no backwards compatible way of mimic the behaviour correctly using kernel-internal unveil hackery.
Prompted by a report from David Leadbeater; and extensive conversations with beck and semarie.

Heads up for #OpenBSD 7.8 users, backports for chromium, iridium, ungoogled-chromium ports have been committed, updated -stable packages should be showing up in the next few days!

chromium has historically only received updates in -current, but it appears sthen@ has managed to backport them!

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

Dave Voutila (dv@) continues his work on multi-process device emulation for #OpenBSD vmd(8), this time moving virtio scsi (CDROM) device emulation to a separate process, further reducing the amount of code running in-process for VMs.

dv@ modified src/usr.sbin/vmd/*: vmd(8): convert virtio scsi device to a subprocess.

Break the virtio scsi device (used as a cd-rom drive) into a subprocess like the virtio block and network devices. This leaves only the entropy device (viornd) and vmmci device running in-process with the vcpus.

ok mlarkin@

This follows up on work presented by Dave at EuroBSDCon 2024.

https://www.youtube.com/watch?v=qKrxVzS96BM

https://www.openbsd.org/papers/eurobsdcon2024-vmd_multiprocessing.pdf

Not great timing, I know, but I'm thinking a Intel mini PC (e.g: N150, 11th Gen i5/i7) would work for my #OpenBSD testing & hacking, Any help towards this would be greatly appreciated. ​

https://www.paypal.com/donate/?hosted_button_id=ZQJC48GUPB3UU&source=url

https://www.amazon.ca/hz/wishlist/ls/2E7N6O3GTI6JF?sort=custom