Alexander Bluhm <[email protected]> wrote: > On Fri, Mar 13, 2026 at 08:28:04PM +0500, Nikita Kandinov wrote: > > -current 7.9-beta GENERIC.MP#307 amd64 > > > > vmm can not start any virtual machine. The problem occures since > > 2026-03-13-0105 snapshot, build date Thu Mar 12 17:18:18 UTC 2026. > > > > On the previous snapshots (e.g. by 2026-03-12-0105, 2026-03-11-0105) > > there is no trouble with vmm. > > > > Log: > > vmctl: start vm command failed: Cannot allocate memory > > Mar 13 18:54:56 openbsd vmd[20675]: debian: failed to start vm > > Same problem here, looks like a pledge violation in libc
This is not a pledge violation _in libc_ It is a pledge violation in the PROGRAM. vmm_start_vm() is trying to open "/dev/null", when it has imposed pledge and unveil rules which don't permit that. That is no longer allowed. CVSROOT: /cvs Module name: src Changes by: [email protected] 2026/03/12 09:00:58 Modified files: sys/kern : kern_pledge.c Log message: In the pledge_namei() callback, stop looking for the libc special files when the open(2) system call was used, and only do this for __pledge_open(2) which libc will use when it intends to access those files. This breaks compatibility in a pretty major way, but that's the price being paid to undo this historical shortcut I made to satisfy libc's internal requirements and make pledge(2) a possibility. All the other parts are already in the tree. There may be a few dangling issues in ports or base which we'll find over time. In the last few weeks there have been a large number of commits explaining this new rule. > > kern.version=OpenBSD 7.9-beta (GENERIC.MP) #307: Thu Mar 12 18:12:37 MDT 2026 > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > 18913 vmd CALL open(0x8b9fe1e9c73,0x2<O_RDWR>) > 18913 vmd PLDG open, "rpath", errno 1 Operation not permitted > 18913 vmd PSIG SIGABRT SIG_DFL > > Core was generated by `vmd'. > Program terminated with signal SIGABRT, Aborted. > #0 _thread_sys_open () at /tmp/-:2 > > warning: 2 /tmp/-: No such file or directory > (gdb) bt > #0 _thread_sys_open () at /tmp/-:2 > #1 0xfb35274babbbaf91 in ?? () > #2 0x00000e6191e91ec1 in _libc_open_cancel (path=0xe5ea45cdc73 "/dev/null", > flags=2) at /usr/src/lib/libc/sys/w_open.c:36 > #3 0x00000e5ea45e0e03 in vmm_start_vm (imsg=0x7a6e5e452010, > id=0x7a6e5e451fb4, pid=0x7a6e5e451fb0) at /usr/src/usr.sbin/vmd/vmm.c:698 > #4 0x00000e5ea45e0468 in vmm_dispatch_parent (fd=<optimized out>, > p=<optimized out>, imsg=0x7a6e5e452010) at /usr/src/usr.sbin/vmd/vmm.c:144 > #5 0x00000e5ea45dd770 in proc_dispatch (fd=3, event=<optimized out>, > arg=0xe60c0b906b8) at /usr/src/usr.sbin/vmd/proc.c:487 > #6 0x00000e615502d038 in event_process_active (base=0xe611988ec00) > at /usr/src/lib/libevent/event.c:333 > #7 event_base_loop (base=0xe611988ec00, flags=0) > at /usr/src/lib/libevent/event.c:483 > #8 0x00000e5ea45ddfe4 in proc_run (ps=0xe60c0b906a0, > p=0xe5ea4602b60 <procs+128>, procs=<optimized out>, nproc=1, > run=0xe5ea45dffc0 <vmm_run>, arg=0x0) at /usr/src/usr.sbin/vmd/proc.c:433 > #9 0x00000e5ea45dd4eb in proc_init (ps=0xe5ea45cdc73, procs=<optimized out>, > nprocs=0, debug=<optimized out>, argc=2, argv=0x0, proc_id=PROC_VMM) > at /usr/src/usr.sbin/vmd/proc.c:192 > #10 0x00000e5ea45d88c6 in main (argc=<optimized out>, argv=0x7a6e5e4522a8) > at /usr/src/usr.sbin/vmd/vmd.c:705 >
