Re: VDSO on amd64

On Thu, Nov 25, 2021 at 09:53:19PM +0200, Konstantin Belousov wrote:
> On Thu, Nov 25, 2021 at 09:35:53AM +0000, David Chisnall wrote:
> > 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.
> The syscalls itself are not annotated, I consider fixing this after vdso
> lands.
> 
> > 
> > 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.
> Well, yes, the part of it was that the signal was synchronous.  I was always
> curious, how good are unwind tables generated by -fasynchronous-unwind-tables
> with this regard.
> 
> But still, the fact that unwinder stepped over the signal frame amused me.
> 
> > 
> > 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.
> No.
> 
> Moving syscall entry point to VDSO is pointless:
> - it would add one more level of indirection before SYSCALL,
> - we do not have slow syscall entry point on amd64 so there is nothing to
>   choose.
> 
> And optimizing 32bit binaries (where we could implement slightly faster
> syscall entry) is past its importance.
> 
> Basically, we do not have to split libc into libc proper and VDSO, as
> Linux has. We can implement features for syscall boundary from both
> sides of kernel, because libc and kernel are developed under the same
> project.  Usermode timehands, fast signal blocks, upcoming rseq support,
> just to name a few of them, all benefit from this model.
> 
> VDSO is only needed for us to provide the unwind annotations on the signal
> trampoline, in a way expected by unwinders.
> 
> > 
> >  - It looks as if the Linux VDSO mechanism isn't yet using this.  Do you
> > plan on moving it over?
> No.
> 
> > 
> >  - 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).
> Not now.  Randomizing shared page location is not too hard, but there are
> some ABI issues to sort out.  We live with fixed-mapped shared page for
> more than 10 years.

As a point of reference, HardenedBSD's PaX-inspired ASLR
implementation has randomized the shared page for more than half a
decade now without issue. I suspect FreeBSD will find, if applied
properly, randomization of the shared page (now VDSO) likely won't
break anything.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc