LWN: Comments on "VSTATUS, with or without SIGINFO"

VSTATUS, with or without SIGINFO

Shabbyx — Thu, 20 Jan 2022 05:43:05 +0000

s/cc/cp obviously

VSTATUS, with or without SIGINFO

Shabbyx — Thu, 20 Jan 2022 05:42:14 +0000

I would totally use ctrl-t on cc, the lack of progress info on cc, rm etc is horrendous.

Replace signals!

nybble41 — Wed, 12 Jan 2022 02:46:07 +0000

> IMHO an appropriately-designed setuid binary generally should not be in the business of accepting and reading from random file descriptors that it did not open itself.

Do you have any examples of situations where this would be an issue, apart from signalfd()? Passing file descriptors has been a standard part of various protocols for a long time now, including between processes of different privilege levels. The expectation is that reading from a file descriptor has the same effect in both the sending and receiving processes, which would imply that there is no security issue. The signalfd API breaks that expectation.

The problem isn't limited to SUID binaries. The destination could be any process running as a different user. The Wayland clipboard protocol[0], to pick one example, involves sending a file descriptor from the data source to the client obtaining the data, which is expected to read the content from the provided file descriptor after negotiating the format. These processes need not belong to the same user.

Also, /dev/stdin is a potential risk as an inherited FD which the target process does not open itself. Do SUID binaries routinely check FD 0 with fstat() before reading input to verify that it isn't a signalfd file descriptor, as opposed to a file, socket, pipe, tty, etc.—basically anything other than signalfd—which could be a reasonable and safe input source?

The behavior and permissions of a file descriptor should be determined by who opens or creates the descriptor, not who reads from it.

[0] https://wayland.freedesktop.org/docs/html/ch04.html#sect-...

Replace signals!

ibukanov — Tue, 11 Jan 2022 11:23:38 +0000

With various sandboxing forking an extrenal process or even just executing another copy of the application becomes a common practice.

As for pselect if one writes to a pipe in the signal handler, then one does not need that. I wish that somebody would come up with a flag or something not to keep signals blocked across exec similarly to noexec flags to file descriptors, but I guess that writing to a pipe from a signal handler is so common knowledge that nobody bothered.

Replace signals!

roc — Mon, 10 Jan 2022 20:32:43 +0000

I guess the interesting case is when a signal is pending but masked and the process uses pselect to unmask it. In that case it probably makes sense to just deliver the signal normally instead of making signalfd readable.

Replace signals!

roc — Mon, 10 Jan 2022 20:29:51 +0000

I'm not really qualified to comment on the kernel-side implementation details.

> What if you use pselect to unmask a signal which is associated with a signalfd that you are pselecting against?

The signal will be delivered normally and not be received by the signalfd. That seems to be the only reasonable behavior.

Replace signals!

NYKevin — Mon, 10 Jan 2022 19:40:25 +0000

> Synchronous SIGILL/SIGSEGV/SIGBUS already have "automatically unmask and proceed" behavior.

I see. That makes a great deal of sense to me, but I would still be concerned about all of the following:

* What data structure holds the list of pending signals for a given process or thread? How thread-safe is this structure?
* Is it possible to atomically dequeue a signal from the list, without taking a mutex?
* If the above is not currently possible, what would be the performance overhead of modifying the data structure so that it is amenable to atomic operations?
* What does the existing "inject a signal handler" code path look like? Can the dequeue be cleanly separated from the injection, or are they tightly coupled? Presumably, you have to preempt the thread before the dequeue (to prevent the thread from exiting or blocking the signal before you can inject the handler), so I imagine there must be some amount of coupling there...

> I think my preferred behavior for signalfd would be that the signal is available through the fd if and only if it is blocked in the process that is the source of the signalfd, i.e. if the signal is unblocked (by the user or in the synchronous case) then signalfd doesn't get it.

* Does this cause thread-safety issues with pselect, which has to atomically (modify the signal mask) and (wait for FD events)? What if you use pselect to unmask a signal which is associated with a signalfd that you are pselecting against? I should expect that to Just Work (i.e. it always executes the signal handler and never returns a ready-to-read event for the signalfd), regardless of when the signal arrives. Is the current implementation prepared to do that?

Replace signals!

NYKevin — Mon, 10 Jan 2022 19:25:35 +0000

To be fair, that exact same problem applies to pselect, which is POSIX-standardized and supposedly the Right Way to do this.

I'm not really a fan of libraries randomly forking off temporary processes without the application code's knowledge or consent, to be honest. Sure, if a library is specifically designed to do something like implement a process pool, I suppose it's unavoidable, but if you're just forking off a process because you can, then maybe don't do that.

Replace signals!

NYKevin — Mon, 10 Jan 2022 19:18:33 +0000

IMHO an appropriately-designed setuid binary generally should not be in the business of accepting and reading from random file descriptors that it did not open itself. This still leaves the door open to /proc/self/fd shenanigans with inherited file descriptors, but I should hope that the binary calls fstat to confirm that it is interacting with a normal file after opening it.

The basic principle remains, however, that writing setuid binaries is an extremely fragile process and you need to be highly paranoid about absolutely everything. signalfd does not materially change that fact (especially since it's been in Linux "since kernel 2.6.22" according to signalfd(2), so the people who make these binaries really should be aware of it by now...).

Replace signals!

nybble41 — Mon, 10 Jan 2022 15:46:30 +0000

> If you completely ignore it, then it doesn't do anything, so unexpectedly sending someone a signalfd accomplishes nothing from a security perspective, at least as far as I understand its semantics.

Sure, if you completely ignore the received file descriptor it doesn't do anything. The same would apply for the proposed alternative version—just holding a signalfd from another process would have no effect on either process. But generally one would expect the receiving process to *read* from the file descriptor, which for signalfd is the part that affects signal delivery.

Replace signals!

roc — Mon, 10 Jan 2022 09:57:21 +0000

Synchronous SIGILL/SIGSEGV/SIGBUS already have "automatically unmask and proceed" behavior.

I think my preferred behavior for signalfd would be that the signal is available through the fd if and only if it is blocked in the process that is the source of the signalfd, i.e. if the signal is unblocked (by the user or in the synchronous case) then signalfd doesn't get it.

> Anyway, the purpose of signalfd is not to share signals with other processes

Maybe that's not the original purpose, but the whole point of orthogonal API design and "everything is a file" is that you can compose features to address new use cases not anticipated by the designers of the individual APIs.

In rr and Pernosco we have a couple of instances of a non-uncommon case: the user runs a process A that in some cases forwards its work to another process B in an unrelated part of the process tree. We want signals like SIGINT, SIGTERM etc sent to A to be handled in B. signalfd looks like it should work for this, but it doesn't, because it has this very strange behavior that what you read from the file descriptor depends on which process is reading from it. Instead we pretend it's the 1980s and install signal handlers that write data to a pipe.

Replace signals!

ibukanov — Mon, 10 Jan 2022 09:22:28 +0000

From the man page:

As described above, in normal usage one blocks the signals that will be accepted via signalfd(). If spawning a child process to execute a helper program (that does not need the signalfd file descriptor), then, after the call to fork(2), you will normally want to unblock those signals before calling execve(2), so that the helper program can see any signals that it expects to see. Be aware, however, that this won't be possible in the case of a helper program spawned behind the scenes by any library function that the program may call. In such cases, one must fall back to using a traditional signal handler that writes to a file descriptor monitored by select(2), poll(2), or epoll(7).

Surely if one controls the code and does not use libraries that executes processes it is fine. But it easy to forget about that. So in one code I just used a signal handler and pipe. As a bonus the code stays compatible with BSD. What is puzzling is that in all those years since signalfd were added no flag were added to reset blocked signals on exec.

Replace signals!

Cyberax — Mon, 10 Jan 2022 07:34:08 +0000

A signalfd() replacement would just allow an alternative way to call signal(), nothing more. The signal will be delivered through the usual mechanisms (either signalfd or through asynchronous interruption).

That's because a way to asynchronously interrupt a thread is extremely useful for many practical purposes. For example, Golang uses signals to force GC in tight loops without having to poll for it. But you have to jump through lots of hoops to be able to use signals. They are completely useless for libraries or anything that shares address space, like plugins (Flash plugin signal bug comes to mind).

Windows has a similar mechanism: APC (Asynchronous Procedure Calls) - https://docs.microsoft.com/en-us/windows/win32/sync/async... and it's extremely useful for some low-level functionality.

Replace signals!

NYKevin — Mon, 10 Jan 2022 07:23:14 +0000

> How safe is the current behavior? Can you mess up signal handling in another process—perhaps a system service or SUID binary—by sending it an unexpected signalfd file descriptor via Unix-domain sockets, or as an inherited FD?

Current behavior where signalfd always gives your own signals: signalfd does not mask or ignore signals just by existing. If you completely ignore it, then it doesn't do anything, so unexpectedly sending someone a signalfd accomplishes nothing from a security perspective, at least as far as I understand its semantics.

Proposed behavior where signalfd operates cross-thread or cross-process: 🤷‍♂️. I'm having a hard time believing you can maintain the "doesn't block signals automatically" invariant and *also* maintain the "every signal is delivered exactly once" invariant, but I don't know enough about the implementation to say that for sure.

Replace signals!

nybble41 — Mon, 10 Jan 2022 03:37:56 +0000

How safe is the current behavior? Can you mess up signal handling in another process—perhaps a system service or SUID binary—by sending it an unexpected signalfd file descriptor via Unix-domain sockets, or as an inherited FD?

From a security point of view, the process calling signalfd() does not have the capability to block signals in arbitrary other processes, or to access data about those signals, so it should not be possible for it to send a file descriptor with those effects to another process. Even if the receiving process is blocking and getting data about its *own* signals, it's still a security risk since those signal handlers shouldn't be blocked and data about the process state, including code addresses otherwise protected by ASLR, might be leaked. (The receiving process would reasonably assume that any data read from the FD would also have been available to the sender—which is not true for signalfd file descriptors.)

VSTATUS, with or without SIvGINFO

NightMonkey — Mon, 10 Jan 2022 03:10:45 +0000

Just a comment on another use of Ctrl-T from when terminals were heavy and CPU registers had blinking lights:

If one were to come upon terminal either powered off or with a lonely blinking cursor or teletype with no text, what is a quick, non-intrusive way to see if a process is running, or not? Our friend "Ctrl-T". :)

This approach has a practical benefit, too. If the previous user was not really very responsible, or was late for their class/party/wedding/funeral, they could have left their TTY at the input prompt of any program. The next person to not use Ctrl-T, but instead hit space or return or enter could set off whatever was on the other side of that input statement or request... which could be a reboot, a disk erase, a terminal lock, etc.

You see where I'm going with this... ;) Cheers.

Replace signals!

NYKevin — Mon, 10 Jan 2022 03:06:39 +0000

Could you please elaborate? I'm looking through the man page but I don't see any obvious gotchas there...

Replace signals!

ibukanov — Mon, 10 Jan 2022 02:16:08 +0000

There are some nasty interactions with signal blocking that made signalfd much less useful to the point that writing to a pipe in a signal handler and listening on that in the event loop is still preferable.

Replace signals!

NYKevin — Sun, 09 Jan 2022 22:33:09 +0000

I would be very surprised if it were possible to do that in a completely safe, race-free, and performant way without forcing process A to mask all signals (which signalfd does not actually require). Because if process B dequeues a signal sent to A, then A should not receive that signal, right? But then, what would you do if process A receives e.g. a SIGILL or SIGBUS? Process A can't mask those signals, because it would just get stuck. So now you have to carve out an exception for signals which would block a process's forward progress if not handled the traditional way. I'm not sure exactly what that would end up looking like, but it would probably be a damned mess on the userspace side at least.

Anyway, the purpose of signalfd is not to share signals with other processes, it's to make signals less painful for people who are already in the business of writing an epoll/select loop, and don't want to faff about with pselect, signal handlers, etc. For this purpose, it works just fine.

VSTATUS, with or without SIGINFO

mm7323 — Sun, 09 Jan 2022 16:57:47 +0000

Neat. It also allows SIGUSR2 to be chosen instead (which I commonly use for various reasons).

VSTATUS, with or without SIGINFO

jrtc27 — Sat, 08 Jan 2022 17:21:07 +0000

On FreeBSD it's not just dd, ping and sleep. The full list is:

* bin/chflags
* bin/chmod
* bin/cp
* bin/dd
* bin/rm
* bin/sleep
* sbin/devd (like udev)
* sbin/dump (creates a full dump from a UFS filesystem that can be later restored)
* sbin/fsck_ffs
* sbin/newfs_msdos
* sbin/ping
* sbin/savecore (kernel core dumps)
* usr.bin/du
* usr.bin/fetch (lightweight curl/wget equivalent)
* usr.bin/gzip
* usr.bin/sort
* usr.bin/time
* usr.bin/wc
* usr.sbin/camdd (like dd but can use pass(4) for issuing asynchronous reads/writes directly to the CAM storage layer in the kernel)
* usr.sbin/chown

So it turns out people tend to add support for features if they exist and not when they don't.

VSTATUS, with or without SIGINFO

fw — Sat, 08 Jan 2022 11:50:18 +0000

And for that, you don't even need support in the kernel, it's sufficient to register the process with some monitor daemon. The kernel can then use some appropriate form of IPC to request status information.

Replace signals!

roc — Sat, 08 Jan 2022 09:18:31 +0000

signalfd is fundamentally broken. If you call signalfd in process A and send it to process B, you would expect process B to be able to observe signals to process A. In fact the fd will observe signals to process *B*. I don't know who decided that was a good idea, but it cripples the feature.

Replace signals!

Cyberax — Fri, 07 Jan 2022 19:17:05 +0000

Signalfd allows to monitor for signals using file descriptors, not to raise them.

VSTATUS, with or without SIGINFO

bof — Fri, 07 Jan 2022 18:52:04 +0000

Ah yes, making it opt-in per session. Got it.

VSTATUS, with or without SIGINFO

flussence — Fri, 07 Jan 2022 17:54:05 +0000

The downside to this is the high possibility of fat-fingering the status key. There's at least six sysrq letters that'll instantly kill a running system.

Replace signals!

flussence — Fri, 07 Jan 2022 17:49:28 +0000

Sounds a bit like the systemd/s6 daemon status protocols to me...

VSTATUS, with or without SIGINFO

abatters — Fri, 07 Jan 2022 14:34:57 +0000

FYI, sysrq isn't limited to the system console:

echo t > /proc/sysrq-trigger
dmesg

Replace signals!

mathstuf — Fri, 07 Jan 2022 12:10:36 +0000

Is this not what signalfd(2) is for?

VSTATUS, with or without SIGINFO

dveeden — Fri, 07 Jan 2022 10:41:44 +0000

The ^T is interesting.

http://dtrace.org/blogs/brendan/2013/10/05/control-t-for-...

VSTATUS, with or without SIGINFO

neilbrown — Fri, 07 Jan 2022 09:34:13 +0000

Presumably there would be a new termios setting to choose the control character, and it could default to NONE.

VSTATUS, with or without SIGINFO

taladar — Fri, 07 Jan 2022 08:24:10 +0000

That also would not work over SSH or in other non-system-console contexts.

VSTATUS, with or without SIGINFO

bof — Fri, 07 Jan 2022 07:32:04 +0000

I don't understand how this can be considered at all, and not for the signal part of it:

tty/pty suddenly reacting to Ctrl-T, will be a regression for anything now sending ctrl-T through e.g. an ssh session to some remote process and not requesting no-pty, whatever the use of that might be - and use cases doing that, would then break.

Right?

Replace signals!

Cyberax — Fri, 07 Jan 2022 06:17:51 +0000

Perhaps it would be a good time to start _replacing_ signals instead? With a centralized way to allocate signal numbers, and a better way to raise them.

One simple proposal:
1. Use file descriptors for signal numbers.
2. Signals are raised by writing a special "struct signal_info_t" into that descriptor.
3. Third-party processes can either receive the descriptor through usual descriptor sending means or use "/proc/pid/<fd>" files.
4. Signals are delivered asynchronously, with the usual semantics. With a way to get the copy of signal_info_t associated with the signal.

This would make signals so much more usable.

VSTATUS, with or without SIGINFO

alison — Fri, 07 Jan 2022 05:52:49 +0000

Documentation/admin-guide/sysrq.rst already shows

``t`` Will dump a list of current tasks and their information to your
console.

which seems inspired by Ctrl-T signals. It is a bit hard to see why another signal is needed.

VSTATUS, with or without SIGINFO

alison — Fri, 07 Jan 2022 05:39:20 +0000

What about extending sysrq? It's already well-known and seems to be easier to extend than signals.

VSTATUS, with or without SIGINFO

neilbrown — Fri, 07 Jan 2022 05:26:28 +0000

Why not have both.
Arrange that fcntl(F_SETSIG) on the tty fd can cause the requested signal to be sent for the status request.

VSTATUS, with or without SIGINFO

wahern — Fri, 07 Jan 2022 03:28:23 +0000

Oops. I pasted the wrong comment, but link is to the intended comment. Basically, it picks one thread within one foreground process to report on.

VSTATUS, with or without SIGINFO

wahern — Fri, 07 Jan 2022 03:05:46 +0000

> > A SIGINFO signal is sent to the process running on the terminal
>
> Because of course there is only one process running on a terminal at a time.

Technically SIGINFO is sent to the foreground process group: https://github.com/openbsd/src/blob/5a74f40/sys/kern/tty..... But for the kernel-generated message, it seems the kernel picks just one foreground process to report on. On OpenBSD the relevant code (https://github.com/openbsd/src/blob/5a74f40/sys/kern/tty....) in ttyinfo is commented thusly,

/*
* Find the most active thread:
* - prefer runnable
* - prefer higher pctcpu
* - prefer living
* Otherwise take the newest thread
*/

The termios(4) manual page STATUS description on FreeBSD and macOS comport with that behavior.

> I wonder what happens if multiple processes in a pipeline respond to the signal. Do their status messages get intermingled?

AFAICT, yes, but that's not really any different than other situations where multiple processes share stderr. Normally message formatting and write atomicity (up to PIPE_BUF, maybe more if writes to a TTY have better guarantees?) will preserve line boundaries if only by accident, and in interactive sessions usually that's good enough. That said, the OpenBSD code sends SIGINFO *before* printing the kernel message, and it doesn't look like there's any buffering involved. ttyprintf calls kprintf without the optional output buffer, which results in kprintf printing the formatted message byte-by-byte straight to the tty (kprintf -> kputchar -> tputchar -> ttyoutput). See subr_prf.c and tty.c. But maybe there's some buffering lower down in the tty layer or higher up with a lock on the TTY? (I've expended my curiosity.) If not it would seem better to print the kernel diagnostic before invoking SIGINFO.

VSTATUS, with or without SIGINFO

kschendel — Fri, 07 Jan 2022 02:29:32 +0000

> Because of course there is only one process running on a terminal at a time. Pipelines don't exist..

Well, of course they don't. It was TOPS-10. A process either belonged to a terminal, or was a daemon. In fact, the word "process" wasn't used much, outside of register W being the PDB (process data block). A more commonly used term was "job".

This brings back (mostly) fond memories of hammering on control-T to find out whether the internal dev KL10 had crashed again or not. Realistically, control-T was usually about as useful as an elevator Close Door button, but much more rewarding.