Project

General

Profile

Feature #13273

want upanic(2)

Added by Robert Mustacchi 4 months ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Category:
kernel
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

When terminating a process due to an erroneous condition, the common trend is to use abort(). This has a number of challenges:

1. It ends up potentially calling the program's abort signal handler, which might do bad things
2. It ends up looping, performing a number of different system call in an attempt to get things to a point that a SIGABRT can take effect

While abort(3C) should not change, in the vein of implementing the stack protector in libc per #5788, it would be valuable to have a system call that just guarantees that the process aborts and exits no matter what and optionally can convey a message in an elfnote to someone debugging it. This has use in a number of other ways. Programs like libc (for mutex errors), fmd, varpd, and others have all tried to come up with different internal panic mechanisms that ensure that core dump occurs and the program terminates with messages. Having a uniform means of this that doesn't have the drawbacks of abort would be great.

This change adds a new system call upanic(2) that ha the signature void noreturn upanic(const void *msg, size_t len). It will copy up to the MIN bytes into an elf note (the upper bound on size is something that we can change, it is not a guarantee of the API). In most cases msg is expected to be a string, but there is no requirement there. A message is not required. If the message cannot be copied in, the program will still terminate and this will be noted in the elf note. Similarly, if the requested length is larger than can be honored, it will be truncated and that will be noted in the elf note. Critically the kernel does zero interpretation of this data. The kernel is merely passing it on. This is done out of a sense of trying to minimize risk and the fact that while we expect that using it for a string message will be the most common, there is no reason that it can't be used for binary data.

In addition, this teaches truss, mdb, and elfdump about this note. Here is an example of using upanic through the stack smashing protection:

rm@beowulf:/ws/rm/ssp/usr/src$ pfexec mdb /var/cores/core.sshd.101320 
Loading modules: [ libc.so.1 libuutil.so.1 libnvpair.so.1 libsmbios.so.1 libavl.so.1 libproc.so.1: ld.so.1 ]
> ::status
debugging core file of sshd (64-bit) from beowulf
file: /usr/sbin/sshd
initial argv: /usr/sbin/sshd -R
threading model: native threads
status: process panicked
upanic message: *** stack smashing detected

Related issues

Blocks illumos gate - Feature #5788: Want support for GCC's stack protector in libcClosedRobert Mustacchi2015-04-03

Actions

Also available in: Atom PDF