Date: Thu, 25 Nov 2021 09:35:53 +0000 From: David Chisnall <theraven@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Re: VDSO on amd64 Message-ID: <7e7f4ba7-16b3-fa6e-fa1d-e9df957e91f1@FreeBSD.org> In-Reply-To: <YZ72kgvfGR5D%2Bzs2@kib.kiev.ua> References: <YZ72kgvfGR5D%2Bzs2@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Great news! Note that your example of throwing an exception from a signal handler works because the signal is delivered during a system call. The compiler generates correct unwind tables for calls because any call may throw. If you did something like a division by zero to get a SIGFPE or a null-pointer dereference to get a SIGSEGV then the throw would probably not work (or, rather, would be delivered to the right place but might corrupt some register state). Neither clang nor GCC currently supports non-call exceptions by default. This mechanism is more useful for Java VMs and similar. Some Linux-based implementations (including Android) use this to avoid null-pointer checks in Java. The VDSO mechanism in Linux is also used for providing some syscall implementations. In particular, getting the current approximate time and getting the current CPU (either by reading from the VDSO's data section or by doing a real syscall, without userspace knowing which). It also provides the syscall stub that is used for the kernel transition for all 'real' syscalls. This doesn't matter so much on amd64, but on i386 it lets them select between int 80h, syscall or sysenter, depending on what the hardware supports. A few questions about future plans: - Do you have plans to extend the VDSO to provide system call entry points and fast-path syscalls? It would be really nice if we could move all of the libsyscalls bits into the VDSO so that any compartmentalisation mechanism that wanted to interpose on syscalls just needed to provide a replacement for the VDSO. - It looks as if the Linux VDSO mechanism isn't yet using this. Do you plan on moving it over? - I can't quite tell from kern_sharedpage.c (this file has almost no comments) - is the userspace mapping of the VDSO randomised? This has been done on Linux for a while because the VDSO is an incredibly high-value target for code reuse attacks (it can do system calls and it can restore the entire register state from the contents of an on-stack buffer if you can jump into it). David On 25/11/2021 02:36, Konstantin Belousov wrote: > I have mostly finished implementation of "proper" vdso for amd64 > native binaries, both 64bit and 32bit. Vdso wraps signal trampolines > into real dynamic shared object, which is prelinked into dynamically > linked image. > > The main (and in fact, now the only) reason for wrapping trampolines > into vdso is to provide proper unwind annotation for the signal frame, > without a need to teach each unwinder about special frame types. In > reality, most of them are already aware of our signal trampolines, > since there is no other way to walk over them except to match > instructions sequence in the frame. Also, we provide sysctl > kern.proc.sigtramp which reports the location of the trampoline. > > So this patch should not make much difference for e.g. gdb or lldb. > On the other hand, I noted that llvm13 unwinder with vdso is able to > catch exceptions thrown from the signal handler, which was a suprise > to me. Corresponding test code is available at > https://gist.github.com/b886401fcc92dc37b49316eaf0e871ca > > Another advantage for us is that having vdso allows to change > trampoline code without breaking unwinders. > > Vdso's for both 64bit and 32bit ABI are put into existing shared page. > This means that total size of both objects should be below 4k, and > some more space needs to be left available, for stuff like timehands > and fxrng. Using linker tricks, which is where the most complexity in > this patch belongs, I was able to reduce size of objects below 1.5k. > I believe some more space saving could be achieved, but I stopped > there for now. Or we might extend shared region object to two pages, > if current situation appears to be too tight. > > The implementation can be found at https://reviews.freebsd.org/D32960 > > Signal delivery for old i386 elf (freebsd 4.x) and a.out binaries was > not yet tested. > > Your reviews, testing, and any other form of feedback is welcomed. > The work was sponsored by The FreeBSD Foundation. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7e7f4ba7-16b3-fa6e-fa1d-e9df957e91f1>