On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote:
>
> > On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > > * Ingo Molnar <mi...@kernel.org> wrote:
> > >
> > > > > +#define __HAVE_ARCH_REMAP
> > > > > +static inline void arch_remap(struct mm_struct *mm,
> > > > > + unsigned long old_start, unsigned long
> > > > > old_end,
> > > > > + unsigned long new_start, unsigned long
> > > > > new_end)
> > > > > +{
> > > > > + /*
> > > > > + * mremap() doesn't allow moving multiple vmas so we can limit
> > > > > the
> > > > > + * check to old_start == vdso_base.
> > > > > + */
> > > > > + if (old_start == mm->context.vdso_base)
> > > > > + mm->context.vdso_base = new_start;
> > > > > +}
> > > >
> > > > mremap() doesn't allow moving multiple vmas, but it allows the
> > > > movement of multi-page vmas and it also allows partial mremap()s,
> > > > where it will split up a vma.
> > >
> > > I.e. mremap() supports the shrinking (and growing) of vmas. In that
> > > case mremap() will unmap the end of the vma and will shrink the
> > > remaining vDSO vma.
> > >
> > > Doesn't that result in a non-working vDSO that should zero out
> > > vdso_base?
> >
> > Right. Now we can't completely prevent the user from shooting itself
> > in the foot I suppose, though there is a legit usage scenario which
> > is to move the vDSO around which it would be nice to support. I
> > think it's reasonable to put the onus on the user here to do the
> > right thing.
>
> I argue we should use the right condition to clear vdso_base: if the
> vDSO gets at least partially unmapped. Otherwise there's little point
> in the whole patch: either correctly track whether the vDSO is OK, or
> don't ...
Well, if we are going to clear it at all yes, we should probably be a
bit smarter about it. My point however was we probably don't need to be
super robust about dealing with any crazy scenario userspace might
conceive.
> There's also the question of mprotect(): can users mprotect() the vDSO
> on PowerPC?
Nothing prevents it. But here too, I wouldn't bother. The user might be
doing on purpose expecting to catch the resulting signal for example
(though arguably a signal from a sigreturn frame is ... odd).
Cheers,
Ben.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
