Skip site navigation (1)Skip section navigation (2)
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>