Index | Thread | Search

From:
"Sven F." <sven.falempin@gmail.com>
Subject:
vmd and vnd, Pledge is great, why not honour chown on devices (a thought experiment)
To:
tech@openbsd.org
Date:
Tue, 20 Oct 2026 10:10:28 -0400

Download raw body.

Thread
  • Sven F.:

    vmd and vnd, Pledge is great, why not honour chown on devices (a thought experiment)

Hi all,

This is a thought experiment about disks and vmd. It has possible
practical applications, but it's extremely ugly.
Nevertheless, it's a good way to look at some pledge internals and
other guardrails.

It works :

# vmctl start -m512M -c -L -d /dev/vnd0c newvm
Connected to /dev/ttyp6 (speed 115200)
Using drive 0, partition 3.
Loading......
probing: pc0 com0 mem[576K 510M a20=on]
disk: hd0+
>> OpenBSD/amd64 BOOT 3.68
boot>

It assumes the vnd was initialized ( a newfs on it or some fdisk ), I
did not remove pledge or unveil.

Attaching a disk directly could ideally mirror hardware pass-through concepts.
Using vnd (or eventually physical devices like sd) is super convenient
for portability.
Like unplug a drive, move it, and boot it directly elsewhere.

Forcing DIOCGDINFO to be root-only is understandable from a historical
standpoint,
but what is the actual security boundary being protected here? ( in read mode )
Hiding disk geometry via an ioctl restriction doesn't do much when
anyone can read
the raw bytes of sector 0 or byte offset 8192 (pread) anyway to figure
out the size.

The current restrictions make passing descriptors or device nodes
through imsg feel a bit awkward.

My conclusion is since pledge works great, disklabel pledge is enough
and having the old super user check overkill,
maybe those kinds of historical checks could be passed in a
pledged/unveiled program.

Just a thought.

(diff attached to ensure tabs are in)

Happy 8.0 OpenBSD,