From: Alyssa Ross <hi@alyssa.is>
To: Demi Marie Obenour <demiobenour@gmail.com>
Cc: Yureka Lilian <yureka@cyberchaos.dev>, devel@spectrum-os.org
Subject: Re: [PATCH] host/rootfs: fix vm-console
Date: Wed, 24 Jun 2026 10:47:28 +0200 [thread overview]
Message-ID: <8733yc72an.fsf@alyssa.is> (raw)
In-Reply-To: <2ce58534-97a7-4846-9f6d-30aa7b044078@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3440 bytes --]
Demi Marie Obenour <demiobenour@gmail.com> writes:
> On 6/20/26 15:46, Alyssa Ross wrote:
>> cloud-hypervisor was being run with its own /dev/pts, so vm-console
>> couldn't find the VM PTY to open it. Furthermore, for Cloud
>> Hypervisor to actually use the global /dev/pts now that it runs as
>> non-root, it needs to be able to open /dev/pts/ptmx. ptmxmode=666
>> matches how systemd mounts /dev/pts.
>>
>> Fixes: 6138e44a ("host/rootfs: run Cloud Hypervisor as non-root")
>> Fixes: ec47d362 ("host/rootfs: Sandbox Cloud Hypervisor")
>> Signed-off-by: Alyssa Ross <hi@alyssa.is>
>> ---
>> Posting to the list in particular to give a chance to anybody who
>> wants to tell me the sandboxing should be done a different way.
>>
>> host/rootfs/image/etc/fstab | 2 +-
>> host/rootfs/image/usr/bin/run-vmm | 1 +
>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/host/rootfs/image/etc/fstab b/host/rootfs/image/etc/fstab
>> index 18bb5e45..4d52a1da 100644
>> --- a/host/rootfs/image/etc/fstab
>> +++ b/host/rootfs/image/etc/fstab
>> @@ -1,7 +1,7 @@
>> # SPDX-License-Identifier: CC0-1.0
>> # SPDX-FileCopyrightText: 2020-2021, 2025 Alyssa Ross <hi@alyssa.is>
>> proc /proc proc nosuid,nodev,noexec 0 0
>> -devpts /dev/pts devpts nosuid,noexec,gid=5,mode=620 0 0
>> +devpts /dev/pts devpts nosuid,noexec,gid=5,mode=620,ptmxmode=666 0 0
>> tmpfs /dev/shm tmpfs nosuid,nodev 0 0
>> tmpfs /media tmpfs nosuid,nodev,noexec,nosymfollow,mode=755 0 0
>> sysfs /sys sysfs nosuid,nodev,noexec 0 0
>> diff --git a/host/rootfs/image/usr/bin/run-vmm b/host/rootfs/image/usr/bin/run-vmm
>> index 94199434..6967dc55 100755
>> --- a/host/rootfs/image/usr/bin/run-vmm
>> +++ b/host/rootfs/image/usr/bin/run-vmm
>> @@ -93,6 +93,7 @@ bwrap
>> --unshare-user
>> --dev /dev
>> --dev-bind /dev/kvm /dev/kvm
>> + --dev-bind /dev/pts /dev/pts
>> --dev-bind /dev/vfio /dev/vfio
>> --tmpfs /dev/shm
>> --tmpfs /tmp
>>
>> base-commit: 57bf21eaf65ca5a42d18999ba65f96dcd338113c
>
> My understanding is that the only reason to use an actual PTY is
> to forward dimension changes. Do we really need this, given that
> vm-console is only for debugging? As long as the VM has xterm-resize
> installed, it's possible to sync the dimensions manually. I'd prefer
> to lose dimension change forwarding instead of weakening the sandbox.
>
> This is worse, but it's manageable. I worked in a Qubes VM for quite
> a while this way, as I was writing a replacement for the GUI daemon
> and so the in-VM GUI was not available when the custom code was not
> running (or not working).
>
> A better (and, hopefully, straightforward) solution would be to
> carry dimension information in-band using specific escape sequences.
> This could either be supported natively in terminal emulators, or
> could implemented by a simple proxy otherwise.
Eventually I would like to just have a terminal emulator inside every
VM, rather than exposing a host terminal emulator to who knows what
weird escape sequences from the VM, so I don't think new protocols to
transmit dimensions would be a good investment. In the meantime,
though, I'd like previously working functionality back. Using a
terminal emulator without size information is absolutely horrible,
because line endings are messed up and long lines become very difficult
to read correctly.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
prev parent reply other threads:[~2026-06-24 8:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-20 19:46 [PATCH] host/rootfs: fix vm-console Alyssa Ross
2026-06-21 1:31 ` Demi Marie Obenour
2026-06-24 8:47 ` Alyssa Ross [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8733yc72an.fsf@alyssa.is \
--to=hi@alyssa.is \
--cc=demiobenour@gmail.com \
--cc=devel@spectrum-os.org \
--cc=yureka@cyberchaos.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).