cloud-hypervisor/vmm/src/clone3.rs

// Copyright 2021 Alyssa Ross <hi@alyssa.is>
// SPDX-License-Identifier: Apache-2.0

use libc::{c_long, size_t, syscall, SYS_clone3};

pub const CLONE_CLEAR_SIGHAND: u64 = 0x100000000;

#[repr(C)]
#[derive(Default)]
#[allow(non_camel_case_types)]
pub struct clone_args {
    pub flags: u64,
    pub pidfd: u64,
    pub child_tid: u64,
    pub parent_tid: u64,
    pub exit_signal: u64,
    pub stack: u64,
    pub stack_size: u64,
    pub tls: u64,
    pub set_tid: u64,
    pub set_tid_size: u64,
    pub cgroup: u64,
}

pub unsafe fn clone3(args: &mut clone_args, size: size_t) -> c_long {
    syscall(SYS_clone3, args, size)
}
vmm: notify virtio-console of pty resizes When a pty is resized (using the TIOCSWINSZ ioctl -- see ioctl_tty(2)), the kernel will send a SIGWINCH signal to the pty's foreground process group to notify it of the resize. This is the only way to be notified by the kernel of a pty resize. We can't just make the cloud-hypervisor process's process group the foreground process group though, because a process can only set the foreground process group of its controlling terminal, and cloud-hypervisor's controlling terminal will often be the terminal the user is running it in. To work around this, we fork a subprocess in a new process group, and set its process group to be the foreground process group of the pty. The subprocess additionally must be running in a new session so that it can have a different controlling terminal. This subprocess writes a byte to a pipe every time the pty is resized, and the virtio-console device can listen for this in its epoll loop. Alternatives I considered were to have the subprocess just send SIGWINCH to its parent, and to use an eventfd instead of a pipe. I decided against the signal approach because re-purposing a signal that has a very specific meaning (even if this use was only slightly different to its normal meaning) felt unclean, and because it would have required using pidfds to avoid race conditions if cloud-hypervisor had terminated, which added complexity. I decided against using an eventfd because using a pipe instead allows the child to be notified (via poll(2)) when nothing is reading from the pipe any more, meaning it can be reliably notified of parent death and terminate itself immediately. I used clone3(2) instead of fork(2) because without CLONE_CLEAR_SIGHAND the subprocess would inherit signal-hook's signal handlers, and there's no other straightforward way to restore all signal handlers to their defaults in the child process. The only way to do it would be to iterate through all possible signals, or maintain a global list of monitored signals ourselves (vmm:vm::HANDLED_SIGNALS is insufficient because it doesn't take into account e.g. the SIGSYS signal handler that catches seccomp violations). Signed-off-by: Alyssa Ross <hi@alyssa.is> 2021-09-10 11:12:17 +00:00			`// Copyright 2021 Alyssa Ross <hi@alyssa.is>`
			`// SPDX-License-Identifier: Apache-2.0`

			`use libc::{c_long, size_t, syscall, SYS_clone3};`

			`pub const CLONE_CLEAR_SIGHAND: u64 = 0x100000000;`

			`#[repr(C)]`
			`#[derive(Default)]`
			`#[allow(non_camel_case_types)]`
			`pub struct clone_args {`
			`pub flags: u64,`
			`pub pidfd: u64,`
			`pub child_tid: u64,`
			`pub parent_tid: u64,`
			`pub exit_signal: u64,`
			`pub stack: u64,`
			`pub stack_size: u64,`
			`pub tls: u64,`
			`pub set_tid: u64,`
			`pub set_tid_size: u64,`
			`pub cgroup: u64,`
			`}`

			`pub unsafe fn clone3(args: &mut clone_args, size: size_t) -> c_long {`
			`syscall(SYS_clone3, args, size)`
			`}`