* Laurent Dufour [off-list ref] wrote:

quoted

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 ...

That's a good option, but it may be hard to achieve in the case the 
vDSO area has been splitted in multiple pieces.

Not sure there is a right way to handle that, here this is a best 
effort, allowing a process to unmap its vDSO and having the 
sigreturn call done through the stack area (it has to make it 
executable).

Anyway I'll dig into that, assuming that the vdso_base pointer 
should be clear if a part of the vDSO is moved or unmapped. The 
patch will be larger since I'll have to get the vDSO size which is 
private to the vdso.c file.

At least for munmap() I don't think that's a worry: once unmapped 
(even if just partially), vdso_base becomes zero and won't ever be set 
again.

So no need to track the zillion pieces, should there be any: Humpty 
Dumpty won't be whole again, right?

quoted

There's also the question of mprotect(): can users mprotect() the 
vDSO on PowerPC?

Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and 
certainly all the other architectures. Furthermore, if it is done on 
a partial part of the vDSO it is splitting the vma...

btw., CRIU's main purpose here is to reconstruct a vDSO that was 
originally randomized, but whose address must now be reproduced as-is, 
right?

In that sense detecting the 'good' mremap() as your patch does should 
do the trick and is certainly not objectionable IMHO - I was just 
wondering whether we could make a perfect job very simply.

Thanks,

	Ingo