arch_check_bp_in_kernelspace: fix the range check

arch/x86/kernel/hw_breakpoint.c int arch_check_bp_in_kernelspace(struct · line 203

Quoted 12 lines · Oleg Nesterov

Note: TASK_SIZE doesn't look right at least on x86, I think it should be replaced by TASK_SIZE_MAX.
...

arch/x86/kernel/hw_breakpoint.c +1 -1

@@ -200,7 +200,7 @@ int arch_check_bp_in_kernelspace(struct
 	va = info->address;
 	len = get_hbp_len(info->len);
 
-	return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
+	return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);

But actully I'd like to ask another question.

Can't we add the additional !in_gate_area_no_mm() check to allow the hw breakpoints in vsyscall?

Quoting Amnon:

My service needs to catch the system-calls of its traced son. Almost all system-calls are caught with PTRACE_SYSCALL, but not those using the vsyscall page - especially "gettimeofday()" and "time()".

...

However, the code in "arch/x86/kernel/ptrace.c" forbids catching kernel addresses.

I tend to agree with Amnon...

What do you think?

Quoted 26 lines · Oleg Nesterov

arch/x86/kernel/hw_breakpoint.c int arch_check_bp_in_kernelspace(struct · line 203

Quoted 12 lines · Oleg Nesterov

Note: TASK_SIZE doesn't look right at least on x86, I think it should be replaced by TASK_SIZE_MAX.
...

arch/x86/kernel/hw_breakpoint.c +1 -1

@@ -200,7 +200,7 @@ int arch_check_bp_in_kernelspace(struct
 	va = info->address;
 	len = get_hbp_len(info->len);
 
-	return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
+	return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);

But actully I'd like to ask another question.

Can't we add the additional !in_gate_area_no_mm() check to allow the hw breakpoints in vsyscall?

Quoting Amnon:

My service needs to catch the system-calls of its traced son. Almost all system-calls are caught with PTRACE_SYSCALL, but not those using the vsyscall page - especially "gettimeofday()" and "time()".

Quoted 8 lines

...

However, the code in "arch/x86/kernel/ptrace.c" forbids catching kernel addresses.

I tend to agree with Amnon...

What do you think?

ping ;)

I agree the patch I sent is very minor (although it looks like the trivial bugfix to me).

Just I think Amnon has a point, shouldn't we change this change like below? (on top of this fixlet).

Oleg.

arch/x86/kernel/hw_breakpoint.c +5 -0

@@ -188,6 +188,11 @@ static int get_hbp_len(u8 hbp_len)
 	return len_in_bytes;
 }
 
+static inline bool bp_in_gate(unsigned long start, unsigned long end)
+{
+	return in_gate_area_no_mm(start) && in_gate_area_no_mm(end);
+}
+
 /*
  * Check for virtual address in kernel space.
  */

arch/x86/kernel/hw_breakpoint.c +0 -0

 }
 
 int arch_bp_generic_fields(int x86_len, int x86_type,

But here, there's no prejudice between tasks. All tasks will now hit the breakpoint regardless of if it is being traced or not.

Is this really what we want? I mean, isn't syscall tracing in the kernel done by a flag set to the task's structure. If the task has a flag set, then it does the slow (ptrace) path which handles the breakpoint for the user.

Quoted 22 lines · Oleg Nesterov

Quoted 4 lines · Oleg Nesterov

Quoted 2 lines

Note: TASK_SIZE doesn't look right at least on x86, I think it

should

Quoted 16 lines

arch/x86/kernel/hw_breakpoint.c int arch_check_bp_in_kernelspace(struct · line 203

Quoted 10 lines

be replaced by TASK_SIZE_MAX.
...

arch/x86/kernel/hw_breakpoint.c +1 -1

@@ -200,7 +200,7 @@ int arch_check_bp_in_kernelspace(struct
 	va = info->address;
 	len = get_hbp_len(info->len);
 
-	return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
+	return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);

But actully I'd like to ask another question.

Can't we add the additional !in_gate_area_no_mm() check to allow the hw breakpoints in vsyscall?

Quoted 7 lines

Quoted 7 lines

Quoting Amnon:

My service needs to catch the system-calls of its traced son. Almost all system-calls are caught with PTRACE_SYSCALL, but not those using the vsyscall page - especially "gettimeofday()" and "time()".

...> Is this really what we want? I mean, isn't syscall tracing in

done by a flag set to the task's structure. If the task has a flag set, then it does the slow (ptrace) path which handles the breakpoint for the user.

Quoted 36 lines

Quoted 2 lines

However, the code in "arch/x86/kernel/ptrace.c" forbids catching

kernel

Quoted 5 lines

addresses.

I tend to agree with Amnon...

What do you think?

ping ;)

I agree the patch I sent is very minor (although it looks like the trivial
bugfix to me).

Just I think Amnon has a point, shouldn't we change this change like below?
(on top of this fixlet).

Oleg.

arch/x86/kernel/hw_breakpoint.c +5 -0

@@ -188,6 +188,11 @@ static int get_hbp_len(u8 hbp_len)
 	return len_in_bytes;
 }
 
+static inline bool bp_in_gate(unsigned long start, unsigned long end)
+{
+	return in_gate_area_no_mm(start) && in_gate_area_no_mm(end);
+}
+
 /*
  * Check for virtual address in kernel space.
  */

arch/x86/kernel/hw_breakpoint.c int arch_check_bp_in_kernelspace(struct · line 209

Quoted 6 lines

arch/x86/kernel/hw_breakpoint.c +2 -1

@@ -200,7 +205,8 @@ int arch_check_bp_in_kernelspace(struct
 	va = info->address;
 	len = get_hbp_len(info->len);
 
-	return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);
+	return ((va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE)) &&
+		!bp_in_gate(va, va + len - 1);

So we want to allow non privileged to add a breakpoint in a vsyscall area even if it happens to lay in kernel space?

Is this really what we want? I mean, isn't syscall tracing in the kernel done by a flag set to the task's structure. If the task has a flag set, then it does the slow (ptrace) path which handles the breakpoint for the user.

But here, there's no prejudice between tasks. All tasks will now hit the breakpoint regardless of if it is being traced or not.

-- Steve

Quoted 3 lines

arch/x86/kernel/hw_breakpoint.c +0 -0

 }
 
 int arch_bp_generic_fields(int x86_len, int x86_type,

Quoted 24 lines · Oleg Nesterov

Just I think Amnon has a point, shouldn't we change this change like below? (on top of this fixlet).

Oleg.

arch/x86/kernel/hw_breakpoint.c +5 -0

@@ -188,6 +188,11 @@ static int get_hbp_len(u8 hbp_len)
 	return len_in_bytes;
 }
 
+static inline bool bp_in_gate(unsigned long start, unsigned long end)
+{
+	return in_gate_area_no_mm(start) && in_gate_area_no_mm(end);
+}
+
 /*
  * Check for virtual address in kernel space.
  */

@@ -200,7 +205,8 @@ int arch_check_bp_in_kernelspace(struct
 	va = info->address;
 	len = get_hbp_len(info->len);
 

arch/x86/kernel/hw_breakpoint.c int arch_check_bp_in_kernelspace(struct · line 209

Quoted 3 lines

arch/x86/kernel/hw_breakpoint.c +2 -1

-	return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);
+	return ((va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE)) &&
+		!bp_in_gate(va, va + len - 1);

So we want to allow non privileged to add a breakpoint in a vsyscall area even if it happens to lay in kernel space?

Is this really what we want?

I mean, isn't syscall tracing in the kernel
done by a flag set to the task's structure. If the task has a flag set, then it does the slow (ptrace) path which handles the breakpoint for the user.

But here, there's no prejudice between tasks. All tasks will now hit the breakpoint regardless of if it is being traced or not.

Quoted 2 lines

But here, there's no prejudice between tasks. All tasks will now hit the breakpoint regardless of if it is being traced or not.

^^^^^^^^^^

This is hardware breakpoint, it is per-task.

Quoted 2 lines · Steven Rostedt

Is this really what we want?

I am not sure, that is why I am asking.

Well yes, with the new implementation __vsyscall_page simply does syscall, so I guess (say) strace will "just work". But, afaics, only if vsyscall_mode == NATIVE.

So perhaps bp in vsyscall_page still makes sense...

Or. Perhaps we can define TRAP_VSYSCALL and change emulate_vsyscall() to do

	if (current->ptrace && test_thread_flag(TIF_SYSCALL_TRACE))
		send_sigtrap(TRAP_VSYSCALL, ...);

if it returns true?

Yes, the tracee won't report _before_ it calls the function, but perhaps this is enough? Amnon?

Quoted 6 lines · Steven Rostedt

Quoted 2 lines

Is this really what we want?

I am not sure, that is why I am asking.

Yes.

And,

Quoted 5 lines

Well yes, with the new implementation __vsyscall_page simply does syscall, so I guess (say) strace will "just work". But, afaics, only if vsyscall_mode == NATIVE.

So perhaps bp in vsyscall_page still makes sense...

Or. Perhaps we can define TRAP_VSYSCALL and change emulate_vsyscall() to do

	if (current->ptrace && test_thread_flag(TIF_SYSCALL_TRACE))
		send_sigtrap(TRAP_VSYSCALL, ...);

if it returns true?

This way the debugger doesn't need to play with the debug registers, it can use ptrace(PTRACE_SYSCALL). The tracee will report SIGTRAP after vsyscall, debugger can detect this case looking at info->si_code.

Yes, the tracee won't report _before_ it calls the function, but perhaps this is enough? Amnon?

Oleg.

Hi Oleg,

Quoted 4 lines

Or. Perhaps we can define TRAP_VSYSCALL and change emulate_vsyscall() to do

Quoted 5 lines

	if (current->ptrace && test_thread_flag(TIF_SYSCALL_TRACE))
		send_sigtrap(TRAP_VSYSCALL, ...);

if it returns true?

I wish it were possible, but the vsyscall page is entered in user-mode,

The vsyscall page was designed in order to avoid user/kernel context switches,

Hi Amnon,

Please read my previous email ;)
http://marc.info/?l=linux-kernel&m=135342649119153

Quoted 7 lines · On 11/21, [email protected] wrote:

Hi Oleg,

Quoted 4 lines

Or. Perhaps we can define TRAP_VSYSCALL and change emulate_vsyscall() to do

Quoted 7 lines

Quoted 5 lines

	if (current->ptrace && test_thread_flag(TIF_SYSCALL_TRACE))
		send_sigtrap(TRAP_VSYSCALL, ...);

if it returns true?

I wish it were possible, but the vsyscall page is entered in user-mode,

Only in NATIVE mode. emulate_vsyscall() runs in kernel mode.

And in the NATIVE mode PTRACE_SYSCALL should work just fine, because:

Quoted 2 lines

The vsyscall page was designed in order to avoid user/kernel context switches,

True, it was. But not today. Please look at __vsyscall_page:

__vsyscall_page:

mov $__NR_gettimeofday, %rax
syscall
ret

If you want the "fast" sys_time() without entering the kernel, you can use __vdso_time(). And since vdso has the user-space mapping you can insert "int3" or use hw breakpoints.

At least this is my understanding after I glanced at the new implementation.

However. It is not that I think that TRAP_VSYSCALL is really good idea. At least it needs another option...

Oleg.

Now however, that "vsyscall" was effectively replaced by vdso, it creates a new problem for me and probably for anyone else who uses some form of checkpoint/restore:

Suppose a process is checkpointed because the system needs to reboot for a kernel-upgrade, then restored on the new and different kernel. The new VDSO page may no longer match the new kernel - it could for example fetch data from addresses in the vsyscall page that now contain different things; or in case the hardware also was changed, it may use machine-instructions that are now illegal.

As I don't mind to forego the "fast" sys_time(), my obvious solution is to disable the vdso for traced processes that may be checkpointed.

One way to do it would be by brute-force: straight after "execve" unmap the tracee's vdso page,

then manipulate the ELF tables in
its memory so the VDSO entry is gone and the library will not go looking for it.

I just wonder whether you know of an easier and more standard way to disable the vdso in user-mode

- ideally on a per-process basis,
or otherwise, if it's too hard, on the whole computer. I searched the web and found references to "/proc/sys/vm/vdso_enable", but I have no such file or "sysctl" option on my system.

Quoted 4 lines · Amnon Shiloh

Now however, that "vsyscall" was effectively replaced by vdso, it creates a new problem for me and probably for anyone else who uses some form of checkpoint/restore:

Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they seem to enjoy trying to solve the c/r problems.

Quoted 6 lines

Suppose a process is checkpointed because the system needs to reboot for a kernel-upgrade, then restored on the new and different kernel. The new VDSO page may no longer match the new kernel - it could for example fetch data from addresses in the vsyscall page that now contain different things; or in case the hardware also was changed, it may use machine-instructions that are now illegal.

Sure. You shouldn't try to save/restore this page(s) directly. But I do not really understand why do you need. IOW, I don't really understand the problem, it depends on what c/r actually does.

Quoted 2 lines

As I don't mind to forego the "fast" sys_time(), my obvious solution is to disable the vdso for traced processes that may be checkpointed.

Quoted 7 lines

Quoted 4 lines

Now however, that "vsyscall" was effectively replaced by vdso, it creates a new problem for me and probably for anyone else who uses some form of checkpoint/restore:

Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they seem to enjoy trying to solve the c/r problems.

Thank you :)

Quoted 6 lines

Quoted 6 lines

Suppose a process is checkpointed because the system needs to reboot for a kernel-upgrade, then restored on the new and different kernel. The new VDSO page may no longer match the new kernel - it could for example fetch data from addresses in the vsyscall page that now contain different things; or in case the hardware also was changed, it may use machine-instructions that are now illegal.

If we could make VDSO entry points not move across the kernels (iow, make them looks as yet another syscall table) this would help, I suppose.

Quoted 4 lines

Sure. You shouldn't try to save/restore this page(s) directly. But I do not really understand why do you need. IOW, I don't really understand the problem, it depends on what c/r actually does.

Think about it like this -- you stop a process, then change the kern^w VDSO page. Everything should work as it used to be :)

Quoted 3 lines

Quoted 3 lines

As I don't mind to forego the "fast" sys_time(), my obvious solution is to disable the vdso for traced processes that may be checkpointed.

This is very poor solution from my POV. Nobody wants to have their applications work fast only until it's checkpointed.

Thanks,
Pavel

The solution can be to hold all catched signals while in the VDSO page.
...

1) + introduce a kernel feature to prevent
catching signals within the VDSO page (probably a new prctl, or make it the default)

Amnon,

I am going to "ignore" this thread because this is not my area and I can't help anyway. Just one note:

Quoted 4 lines · Amnon Shiloh

The solution can be to hold all catched signals while in the VDSO page.
...

Quoted 3 lines

1) + introduce a kernel feature to prevent
catching signals within the VDSO page (probably a new prctl, or make it the default)

Sorry, never ;)

Oleg.

Quoted 3 lines · Oleg Nesterov

Sure. You shouldn't try to save/restore this page(s) directly. But I do not really understand why do you need. IOW, I don't really understand the problem, it depends on what c/r actually does.

Think about it like this -- you stop a process, then change the kern^w VDSO page. Everything should work as it used to be :)

Quoted 4 lines

Now however, that "vsyscall" was effectively replaced by vdso, it creates a new problem for me and probably for anyone else who uses some form of checkpoint/restore:

Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they seem to enjoy trying to solve the c/r problems.

Quoted 6 lines

Suppose a process is checkpointed because the system needs to reboot for a kernel-upgrade, then restored on the new and different kernel. The new VDSO page may no longer match the new kernel - it could for example fetch data from addresses in the vsyscall page that now contain different things; or in case the hardware also was changed, it may use machine-instructions that are now illegal.

Sure. You shouldn't try to save/restore this page(s) directly. But I do not really understand why do you need. IOW, I don't really understand the problem, it depends on what c/r actually does.

Quoted 5 lines

As I don't mind to forego the "fast" sys_time(), my obvious solution is to disable the vdso for traced processes that may be checkpointed.

One way to do it would be by brute-force: straight after "execve" unmap the tracee's vdso page,

Not sure this will be always possible. For example, my (old) glibc assumes that vsyscall() must work, I won't be surprised if some time later it won't work without vdso. But again, I do not know.

Quoted 3 lines

then manipulate the ELF tables in
its memory so the VDSO entry is gone and the library will not go looking for it.

Probably it would be enough to simply erase AT_SYSINFO_EHDR note, but again, I can be easily wrong.

Quoted 2 lines

I just wonder whether you know of an easier and more standard way to disable the vdso in user-mode

Only the kernel parameter, afaics. vdso=0

Quoted 4 lines

- ideally on a per-process basis,
or otherwise, if it's too hard, on the whole computer. I searched the web and found references to "/proc/sys/vm/vdso_enable", but I have no such file or "sysctl" option on my system.

sys/vm/vdso_enabled, but only if CONFIG_X86_32 for some reason. See kernel/sysctl.c

Oleg.

What I discovered now, is that PTRACE_SYSCALL (also PTRACE_SINGLESTEP) does not work within the vsyscall page, so I cannot trap the kernel-calls there (this is very simple to verify using "gdb" or "strace").

The necessary patch was already discussed and is very simple.

Or, there is an alternative: if only I (the ptracer or the traced process) was allowed to munmap the vsyscall page,

Quoted 3 lines · Amnon Shiloh

Or, there is an alternative: if only I (the ptracer or the traced process) was allowed to munmap the vsyscall page,

It is not possible to unmap it. The kernel (swapper_pg_dir) has this mapping, not the process. Unlike vdso. IOW, you can only "unmap" it globally and obviously you can't do this from the userspace.

forgot to mention...

Quoted 9 lines · Oleg Nesterov

Quoted 3 lines · Amnon Shiloh

Or, there is an alternative: if only I (the ptracer or the traced process) was allowed to munmap the vsyscall page,

It is not possible to unmap it. The kernel (swapper_pg_dir) has this mapping, not the process. Unlike vdso. IOW, you can only "unmap" it globally and obviously you can't do this from the userspace.

And even if this were possible, this can't help. Please look at __bad_area_nosemaphore()->emulate_vsyscall(), the process won't get SIGSEGV. IOW, in fact EMULATE already "unmaps" this page (sets _NX) to trigger the fault.

Sure, we can do something like below, but it doesn't look very nice too.

Oleg.

arch/x86/mm/fault.c +2 -1

@@ -744,7 +744,8 @@ __bad_area_nosemaphore(struct pt_regs *r
 		 */
 		if (unlikely((error_code & PF_INSTR) &&
 			     ((address & ~0xfff) == VSYSCALL_START))) {
-			if (emulate_vsyscall(regs, address))
+			if (!(tsk->ptrace & PTRACE_O_DONTEMULATE) &&
+			    emulate_vsyscall(regs, address))
 				return;
 		}
 #endif

Hello Amnon,

I am a bit confused,

Quoted 4 lines

What I discovered now, is that PTRACE_SYSCALL (also PTRACE_SINGLESTEP) does not work within the vsyscall page, so I cannot trap the kernel-calls there (this is very simple to verify using "gdb" or "strace").

Sure, but we alredy discussed this?

Once again, PTRACE_SYSCALL should work in the NATIVE mode. Obviously it won't work in EMULATE mode but we can change emulate_vsyscall() to report TRAP_VSYSCALL or even introduce PTRACE_EVENT_VSYSCALL.

Quoted 1 line

The necessary patch was already discussed and is very simple.

Do you mean TRAP_VSYSCALL/PTRACE_EVENT_VSYSCALL above or additional in_gate_area_no_mm() check to allow the hw bp?

Quoted 2 lines

Or, there is an alternative: if only I (the ptracer or the traced process) was allowed to munmap the vsyscall page,

It is not possible to unmap it. The kernel (swapper_pg_dir) has this mapping, not the process. Unlike vdso. IOW, you can only "unmap" it globally and obviously you can't do this from the userspace.

Oleg.

2) I was then told (in my own words): "oh, don't worry, the vsyscall page has now been minimized, all it contains now is *real* system calls, and it always calls them".

6) I just suggested an alternative: to have the whole vsyscall page removed on a per-process basis. I accept your reply that this is not possible.

7) I suggested a third alternative: to have the vsyscall page be unexecutable on a per-process basis,

8) Any solution that allows a ptracer to prevent its traced process from entering the vsyscall page and execute there system-calls unchecked (thus in effect escape its jailer), would do for me.

Quoted 3 lines

2) I was then told (in my own words): "oh, don't worry, the vsyscall page has now been minimized, all it contains now is *real* system calls, and it always calls them".

Not sure where did you get this idea ;) From the very beginning you were told that EMULATE mode doesn't do this.

Quoted 3 lines

8) Any solution that allows a ptracer to prevent its traced process from entering the vsyscall page and execute there system-calls unchecked (thus in effect escape its jailer), would do for me.

Well. I am even more confused... probably this was already discussed and I missed this, but.

Why do you need to _prevent_, say, sys_gettimeofday()? Why we can't change emulate_vsyscall() to respect PTRACE_SYSCALL and report TRAP_VSYSCALL or PTRACE_EVENT_VSYSCALL as I tried to suggest in
http://marc.info/?l=linux-kernel&m=135343635523715 ?

Oleg.

You previously replied that this can not work. Now that you see that this _can_ work, could you please explain why this is not enough?

Quoted 8 lines

Why do you need to _prevent_, say, sys_gettimeofday()? Why we can't change emulate_vsyscall() to respect PTRACE_SYSCALL and report TRAP_VSYSCALL or PTRACE_EVENT_VSYSCALL as I tried to suggest in
http://marc.info/?l=linux-kernel&m=135343635523715 ?

Oleg.

For my own application, I would be happy with this.

But I suspect it might break current versions of "strace",
...
I think it COULD work, but not based on PTRACE_SYSCALL
(or PTRACE_SYSEMU) alone. A new ptrace option will be needed, saying:
"Yes, I am aware of TRAP_VSYSCALL and I know how to handle it."

While for my own application, just fixing the range-check in arch_check_bp_in_kernelspace will do,

However. Of course it would be nice to avoid the new option. IMO it would be better to do nothing ;) vsyscall is deprecated, and EMULATE is x86-specific.

You forgot again that EMULATE does not execute the code in the vsyscall page.

Amnon, sorry for delay...

Quoted 10 lines · Amnon Shiloh

Quoted 8 lines

Why do you need to _prevent_, say, sys_gettimeofday()? Why we can't change emulate_vsyscall() to respect PTRACE_SYSCALL and report TRAP_VSYSCALL or PTRACE_EVENT_VSYSCALL as I tried to suggest in
http://marc.info/?l=linux-kernel&m=135343635523715 ?

Oleg.

For my own application, I would be happy with this.

OK, good.

Quoted 5 lines

But I suspect it might break current versions of "strace",
...
I think it COULD work, but not based on PTRACE_SYSCALL
(or PTRACE_SYSEMU) alone. A new ptrace option will be needed, saying:
"Yes, I am aware of TRAP_VSYSCALL and I know how to handle it."

Yes, that is why I said this needs the new option.

However. Of course it would be nice to avoid the new option. IMO it would be better to do nothing ;) vsyscall is deprecated, and EMULATE is x86-specific.

May be we could simply do something like the patch below? (Just in case, this hack is only for illustration, it is not complete).

If the tracer does PTRACE_SYSCALL the tracee reports syscall exit _after_ gettimeofday/etc. The tracer can look at regs->orig_ax == -1 and detect that this is not syscall but vsyscall, it can look at regs->ip then (not with the patch below).

Denys, Jan, Pedro. Do you think this change can break/confuse gdb/strace ?

Quoted 2 lines

While for my own application, just fixing the range-check in arch_check_bp_in_kernelspace will do,

You forgot again that EMULATE does not execute the code in the vsyscall page.

Oleg.

arch/x86/kernel/vsyscall_64.c +2 -0

@@ -186,6 +186,8 @@ static bool write_ok_or_segv(unsigned long ptr, size_t
 size)
 	}
 }
 
+#include <linux/tracehook.h>
+
 bool emulate_vsyscall(struct pt_regs *regs, unsigned long address)
 {

arch/x86/kernel/vsyscall_64.c +2 -0

 	struct task_struct *tsk;

@@ -312,6 +314,8 @@ do_ret:
 	regs->ip = caller;
 	regs->sp += 8;
 done:
+	if (test_thread_flag(TIF_SYSCALL_TRACE))
+		ptrace_report_syscall(regs);
 	return true;
 
 sigsegv:

Quoted 4 lines

However. Of course it would be nice to avoid the new option. IMO it would be better to do nothing ;) vsyscall is deprecated, and EMULATE is x86-specific.

The problem is that the current static glibc invokes the vsyscall page,

Quoted 2 lines

You forgot again that EMULATE does not execute the code in the vsyscall page.

The beauty of using the x86 debug-registers, is that they do not trap the instruction, but rather the fact that the program-counter has a given value.

Yes, I understand, so DR_RW_EXECUTE should probably work. And I even sent the patch (untested/uncompiled). But given that even the simple bugfix which started this thread was ignored by maintainers, I am not sure how we can convince them this change makes sense ;)

But If we want to allow to trace vsyscall's, hw bp doesn't look very nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.

Quoted 6 lines

Quoted 4 lines

However. Of course it would be nice to avoid the new option. IMO it would be better to do nothing ;) vsyscall is deprecated, and EMULATE is x86-specific.

The problem is that the current static glibc invokes the vsyscall page,

Yes I know.

Still I'd like to avoid to change the ptrace API, even if the change is simple. This emulate_vsyscall() is too "exotic" imho.

Quoted 6 lines

Quoted 2 lines

You forgot again that EMULATE does not execute the code in the vsyscall page.

The beauty of using the x86 debug-registers, is that they do not trap the instruction, but rather the fact that the program-counter has a given value.

Yes, I understand, so DR_RW_EXECUTE should probably work. And I even sent the patch (untested/uncompiled). But given that even the simple bugfix which started this thread was ignored by maintainers, I am not sure how we can convince them this change makes sense ;)

However. This looks like a hack to me, because this code is never executed. But this is sudjective and I am not saying this can't work. And yes, this doesn't add new ptrace hacks.

But If we want to allow to trace vsyscall's, hw bp doesn't look very nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.

And what about strace? It won't be easy to change it to use hwbp.

That is why I think PTRACE_SYSCALL should "simply work" somehow. And so far I think that "just report syscall_exit with orig_ax = -1" is the best (and simple) solution.

OK. We can do more. We can report both syscall_enter/exit and we can change orig_ax/ax temporary to "fool" the tracer, so that everything will look as a "normal" syscall. Like vsyscall_seccomp() does.

But this needs much more changes.

Oleg.

But If we want to allow to trace vsyscall's, hw bp doesn't look very nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.

That is why I think PTRACE_SYSCALL should "simply work" somehow. And so far I think that "just report syscall_exit with orig_ax = -1" is the best (and simple) solution.

OK. We can do more. We can report both syscall_enter/exit and we can change orig_ax/ax temporary to "fool" the tracer, so that everything will look as a "normal" syscall. Like vsyscall_seccomp() does.

But this needs much more changes.

Quoted 2 lines · Oleg Nesterov

But If we want to allow to trace vsyscall's, hw bp doesn't look very nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.

Irrespective of the whole syscall tracing issue, allowing HW bkpts in the vsyscall just seems like a bug fix to me.

Quoted 3 lines

That is why I think PTRACE_SYSCALL should "simply work" somehow. And so far I think that "just report syscall_exit with orig_ax = -1" is the best (and simple) solution.

If you report exit alone, you'll confuse current GDB into mistaking it for an enter,

Quoted 5 lines

OK. We can do more. We can report both syscall_enter/exit and we can change orig_ax/ax temporary to "fool" the tracer, so that everything will look as a "normal" syscall. Like vsyscall_seccomp() does.

But this needs much more changes.

I'd just like to add, that if any new syscall related option is to be added, can we please just go all the way and add PTRACE_EVENT_SYSCALL_ENTER|PTRACE_EVENT_SYSCALL_EXIT instead?

Quoted 8 lines · Oleg Nesterov

Quoted 3 lines

But If we want to allow to trace vsyscall's, hw bp doesn't look very nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.

Irrespective of the whole syscall tracing issue, allowing HW bkpts in the vsyscall just seems like a bug fix to me.

And I never argued. I sent the patch iirc ;)

Quoted 7 lines

Quoted 4 lines

That is why I think PTRACE_SYSCALL should "simply work" somehow. And so far I think that "just report syscall_exit with orig_ax = -1" is the best (and simple) solution.

If you report exit alone, you'll confuse current GDB into mistaking it for an enter,

Sure. That is why I asked Jan.

Quoted 9 lines

Quoted 5 lines

OK. We can do more. We can report both syscall_enter/exit and we can change orig_ax/ax temporary to "fool" the tracer, so that everything will look as a "normal" syscall. Like vsyscall_seccomp() does.

But this needs much more changes.

I'd just like to add, that if any new syscall related option is to be added, can we please just go all the way and add PTRACE_EVENT_SYSCALL_ENTER|PTRACE_EVENT_SYSCALL_EXIT instead?

Oh yes, this was suggested many times.

Oleg.

Hi Everyone,

Quoted 7 lines · Pedro Alves

Quoted 6 lines · Oleg Nesterov

Quoted 3 lines

But If we want to allow to trace vsyscall's, hw bp doesn't look very nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all.

Quoted 4 lines

Quoted 2 lines

Irrespective of the whole syscall tracing issue, allowing HW bkpts in the vsyscall just seems like a bug fix to me.

And I never argued. I sent the patch iirc ;)

Exactly, it is a bug and I am still waiting for it to be fixed in the Linux kernel.

I would not say this is a bug but let me repeat, no need to convince me.

Please feel free to re-send the patch(es) I sent to maintainers. Sorry, I can't push these changes into Linus's tree.

Quoted 12 lines

Hi Everyone,

Quoted 5 lines · Pedro Alves

Quoted 4 lines · Oleg Nesterov

Quoted 2 lines

But If we want to allow to trace vsyscall's, hw bp doesn't look

very

Quoted 1 line

Quoted 1 line

Quoted 1 line

nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them

all.

Quoted 1 line

Quoted 1 line

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

Irrespective of the whole syscall tracing issue, allowing HW bkpts in the vsyscall just seems like a bug fix to me.

And I never argued. I sent the patch iirc ;)

Exactly, it is a bug and I am still waiting for it to be fixed in the Linux kernel.

I would not say this is a bug but let me repeat, no need to convince me.

Please feel free to re-send the patch(es) I sent to maintainers. Sorry, I can't push these changes into Linus's tree.

Oleg.

So here again is the patch that I need so badly - clearly it fixes a bug and harms nobody:

-----------------------------------------------------------------------
diff -Naur before/arch/x86/kernel/hw_breakpoint.c
after/arch/x86/kernel/hw_breakpoint.c
--- before/arch/x86/kernel/hw_breakpoint.c 2013-01-14 12:45:20.000000000
+1030
+++ after/arch/x86/kernel/hw_breakpoint.c 2013-01-14 12:46:24.000000000 +1030

Hello,

The code in "kernel/sys.c" provides the "prctl(PR_SET_MM)" function, which is the only way a process can set or modify the following 11 per-process fields:

(quoted diff) +0 -0

 	start_code, end_code, start_data, end_data, start_brk, brk,
 	start_stack, arg_start, arg_end, env_start, env_end.

Being able to set those fields is important, even crucial, for any conceivable user-level checkpointing software, as well as for migrating processes between different computers.

Unfortunately, this code (essentially "prctl_set_mm()") is presently enclosed in "#ifdef CONFIG_CHECKPOINT_RESTORE" which is configured as "default n" in "init/Kconfig". Many system-administrators who may like to have a checkpoint/restore or process-migration facility, but use standard pre-packaged kernels, find the requirement to configure and compile their own non-standard kernel difficult or too prohibitive.

Would it be possible to have this code enabled by default?

This could be done in one of 4 ways:
1) Having CONFIG_CHECKPOINT_RESTORE enabled by default; or
2) Releasing this code from the "#ifdef CONFIG_CHECK_RESTORE"; or
3) Placing this code within a different kernel-configuration option (say "CONFIG_BASIC_CHECKPOINTING") that is enabled by default; or
4) Placing this code under a dual #if, so instead of:

   #ifdef CONFIG_CHECKPOINT_RESTORE
	   have:
   #if defined(CONFIG_CHECKPOINT_RESTORE) || defined(CONFIG_BASIC_CHECKPOINTING)

Hello,

The code in "kernel/sys.c" provides the "prctl(PR_SET_MM)" function, which is the only way a process can set or modify the following 11 per-process fields:

(quoted diff) +0 -0

 	start_code, end_code, start_data, end_data, start_brk, brk,
 	start_stack, arg_start, arg_end, env_start, env_end.

Being able to set those fields is important, even crucial, for any conceivable user-level checkpointing software, as well as for migrating processes between different computers.

Unfortunately, this code (essentially "prctl_set_mm()") is presently enclosed in "#ifdef CONFIG_CHECKPOINT_RESTORE" which is configured as "default n" in "init/Kconfig". Many system-administrators who may like to have a checkpoint/restore or process-migration facility, but use standard pre-packaged kernels, find the requirement to configure and compile their own non-standard kernel difficult or too prohibitive.

Would it be possible to have this code enabled by default?

This could be done in one of 4 ways:
1) Having CONFIG_CHECKPOINT_RESTORE enabled by default; or

2) Releasing this code from the "#ifdef CONFIG_CHECK_RESTORE"; or
3) Placing this code within a different kernel-configuration option (say "CONFIG_BASIC_CHECKPOINTING") that is enabled by default; or
4) Placing this code under a dual #if, so instead of:

   #ifdef CONFIG_CHECKPOINT_RESTORE
	   have:
   #if defined(CONFIG_CHECKPOINT_RESTORE) || defined(CONFIG_BASIC_CHECKPOINTING)

Quoted 9 lines · Amnon Shiloh

Hello,

The code in "kernel/sys.c" provides the "prctl(PR_SET_MM)" function, which is the only way a process can set or modify the following 11 per-process fields:

(quoted diff) +0 -0

 	start_code, end_code, start_data, end_data, start_brk, brk,
 	start_stack, arg_start, arg_end, env_start, env_end.

Quoted 3 lines

Being able to set those fields is important, even crucial, for any conceivable user-level checkpointing software, as well as for migrating processes between different computers.

You're saying that this is useful for code not needing a kernel with CHECKPOINT_RESTORE enabled. Correct?

Quoted 10 lines

Unfortunately, this code (essentially "prctl_set_mm()") is presently enclosed in "#ifdef CONFIG_CHECKPOINT_RESTORE" which is configured as "default n" in "init/Kconfig". Many system-administrators who may like to have a checkpoint/restore or process-migration facility, but use standard pre-packaged kernels, find the requirement to configure and compile their own non-standard kernel difficult or too prohibitive.

Quoted 4 lines

Would it be possible to have this code enabled by default?

This could be done in one of 4 ways:
1) Having CONFIG_CHECKPOINT_RESTORE enabled by default; or

Nope, that wont due. Kernel policy is to have things default n. Have an issue with a config, talk with the distribution you are dealing with. They set the policy of what configs get set for their kernels.

Quoted 8 lines

2) Releasing this code from the "#ifdef CONFIG_CHECK_RESTORE"; or
3) Placing this code within a different kernel-configuration option (say "CONFIG_BASIC_CHECKPOINTING") that is enabled by default; or
4) Placing this code under a dual #if, so instead of:

   #ifdef CONFIG_CHECKPOINT_RESTORE
	   have:
   #if defined(CONFIG_CHECKPOINT_RESTORE) || defined(CONFIG_BASIC_CHECKPOINTING)

One of the above 3 can probably be worked out.

-- Steve

Yes, Randy Dunlap already raised this point, but I have no dealings with any particular Linux distribution or the right connections to chase them all, one by one - I develop generic software for the general Linux community, that is intended to work distribution-independently. Even if I had access to all distributions, it may be hard to convince them to configure CONFIG_CHECKPOINT_RESTORE as a whole since it contains so much other code.

BTW, Can anyone explain this policy of "have things default n"? When I go over "init/Kconfig" or most other Kconfig's, I can actually see lots of "default y".

Quoted 10 lines

Quoted 9 lines

2) Releasing this code from the "#ifdef CONFIG_CHECK_RESTORE"; or
3) Placing this code within a different kernel-configuration option (say "CONFIG_BASIC_CHECKPOINTING") that is enabled by default; or
4) Placing this code under a dual #if, so instead of:

   #ifdef CONFIG_CHECKPOINT_RESTORE
	   have:
   #if defined(CONFIG_CHECKPOINT_RESTORE) || defined(CONFIG_BASIC_CHECKPOINTING)

Quoted 3 lines

One of the above 3 can probably be worked out.

-- Steve

Great!

Naturally I prefer option 2 (but the other two will do as well).

If only you, or a few people are using it (ie. distros don't see a need), then it will be up to you to make the changes.

To reconstruct Linux process(es), one must be able to restore all their memory contents, states and registers to their original and consistent values.

Quoted 4 lines · Amnon Shiloh

To reconstruct Linux process(es), one must be able to restore all their memory contents, states and registers to their original and consistent values.

I personally don't mind if this come become y by default, because it will work for us.

Still I guess if you need to reconstruct Linux process(es) plain prctl extension is not enough, you still need a functionality which is enclosed in config-checkpoint-restore (say /proc/pid/map_files, kcmp), no?

Quoted 2 lines

I personally don't mind if this come become y by default, because it will work for us.

I don't mind either, to say the least, to have CONFIG_CHECKPOINT_RESTORE have a "default y" in "init/Kconfig" - that would solve my problem and make me happy, as well as your group and others, but we are told here that Linus has a policy vetoing such changes and I don't believe either of us can make him change his mind.

As such, we must look at other options, such as having the code in "kernel/sys.c" out in the open, not enclosed by any #ifdef's altogether
- surely you would like that!

Quoted 4 lines

Still I guess if you need to reconstruct Linux process(es) plain prctl extension is not enough, you still need a functionality which is enclosed in config-checkpoint-restore (say /proc/pid/map_files, kcmp), no?

My process-migration package only reconstructs Linux processes partially:
as it's a bit different than any classical checkpoint-restore, the critical code in "kernel/sys.c" is all I need at the moment (from within CONFIG_CHECKPOINT_RESTORE). I do appreciate that anyone attempting to perform complete, classical, checkpoint-restore operations, needs more than that.

I see. Thanks for explanation! Thus we need some new config option which would enable this prctl opcodes (y by default), in turn config-checkpoint-restore kconfig option need to select this feature if set. Sounds reasonable?

Quoted 3 lines

Another possibility is to have a dual #if:

#if defined(CONFIG_CHECKPOINT_RESTORE) || defined(CONFIG_MM_FIELDS_SETTING)

Thus this approach looks preferred. And MM_FIELDS_SETTING will be y by default. Mind to cook a patch and lets see if community accept it? Don't forget to CC Andrew Morton.

Quoted 7 lines · Cyrill Gorcunov

Quoted 3 lines

Another possibility is to have a dual #if:

#if defined(CONFIG_CHECKPOINT_RESTORE) || defined(CONFIG_MM_FIELDS_SETTING)

Thus this approach looks preferred. And MM_FIELDS_SETTING will be y by default. Mind to cook a patch and lets see if community accept it? Don't forget to CC Andrew Morton.

Very well, patch attached.

Wouldn't the below do the same trick but eliminate OR in preproc code?

---
From: Amnon Shiloh <[email protected]>
Subject: prctl: Make PR_SET_MM being depend on own CONFIG_MM_FIELDS_SETTING

...

Signed-off-by Amnon Shiloh <[email protected]>

---
 init/Kconfig |   17 +++++++++++++++++
 kernel/sys.c |   16 ++++++++--------
 2 files changed, 25 insertions(+), 8 deletions(-)

Index: linux-2.6.git/init/Kconfig
===================================================================

init/Kconfig +17 -0

@@ -991,6 +991,7 @@ endif # CGROUPS
 config CHECKPOINT_RESTORE
 	bool "Checkpoint/restore support" if EXPERT
 	default n
+	select MM_FIELDS_SETTING
 	help
 	  Enables additional kernel features in a sake of checkpoint/restore.
 	  In particular it adds auxiliary prctl codes to setup process text,

@@ -999,6 +1000,22 @@ config CHECKPOINT_RESTORE
 
 	  If unsure, say N here.
 
+config MM_FIELDS_SETTING
+	bool "Allow modifying per-process memory-region fields"
+	default y
+	help
+	   Support "prctl(PR_SET_MM)" which allows applications to modify
+	   the following in their "mm_struct":
+
+	      start_code, end_code, start_data, end_data, start_brk, brk,
+	      start_stack, arg_start, arg_end, env_start, env_end.
+
+	    Also to modify their executable file ("/proc/self/exe").
+
+	    This option is needed for reconstructing processes (such as when
+	    restoring a process from a checkpoint; duplicating a process;
+	    or migrating it to another computer).
+
 menuconfig NAMESPACES
 	bool "Namespaces support" if EXPERT
 	default !EXPERT

Index: linux-2.6.git/kernel/sys.c
===================================================================

kernel/sys.c +8 -8

@@ -1788,7 +1788,7 @@ SYSCALL_DEFINE1(umask, int, mask)
 	return mask;
 }
 
-#ifdef CONFIG_CHECKPOINT_RESTORE
+#ifdef CONFIG_MM_FIELDS_SETTING
 static int prctl_set_mm_exe_file(struct mm_struct *mm, unsigned int fd)
 {
 	struct fd exe;

@@ -1981,23 +1981,23 @@ out:
 	up_read(&mm->mmap_sem);
 	return error;
 }
+#else /* CONFIG_MM_FIELDS_SETTING */
 
-static int prctl_get_tid_address(struct task_struct *me, int __user **tid_addr)
-{
-	return put_user(me->clear_child_tid, tid_addr);
-}
-
-#else /* CONFIG_CHECKPOINT_RESTORE */
 static int prctl_set_mm(int opt, unsigned long addr,
 			unsigned long arg4, unsigned long arg5)
 {
 	return -EINVAL;
 }
+#endif
+
 static int prctl_get_tid_address(struct task_struct *me, int __user **tid_addr)
 {
+#ifdef CONFIG_CHECKPOINT_RESTORE
+	return put_user(me->clear_child_tid, tid_addr);
+#else
 	return -EINVAL;
-}
 #endif
+}
 
 SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
 		unsigned long, arg4, unsigned long, arg5)

Hi,

Quoted 1 line · Cyrill Gorcunov

Wouldn't the below do the same trick but eliminate OR in preproc code?

Yes it would. I don't mind having it either way.

From: Amnon Shiloh <[email protected]>
Subject: prctl: Make PR_SET_MM being depend on own CONFIG_MM_FIELDS_SETTING

...

Signed-off-by Amnon Shiloh <[email protected]>

Quoted 5 lines · On Thu, 21 Feb 2013 12:00:28 +0400 Cyrill Gorcunov <[email protected]> wrote:

From: Amnon Shiloh <[email protected]>
Subject: prctl: Make PR_SET_MM being depend on own CONFIG_MM_FIELDS_SETTING

...

Quoted 1 line

Signed-off-by Amnon Shiloh <[email protected]>

The "..." makes me sad.

If/when this patch gets sent for real, please explain the reasons? AFAICT it permits the enabling of prctl(PR_SET_MM) in CONFIG_CHECKPOINT_RESTORE=n kernels. If that was indeed the intent, why?

Quoted 6 lines · On Thu, 21 Feb 2013 12:00:28 +0400 Cyrill Gorcunov <[email protected]> wrote:

From: Amnon Shiloh <[email protected]>
Subject: prctl: Make PR_SET_MM being depend on own CONFIG_MM_FIELDS_SETTING

...

Signed-off-by Amnon Shiloh <[email protected]>

The "..." makes me sad.

If/when this patch gets sent for real, please explain the reasons? AFAICT it permits the enabling of prctl(PR_SET_MM) in CONFIG_CHECKPOINT_RESTORE=n kernels. If that was indeed the intent, why?

Quoted 2 lines · Steven Rostedt

If only you, or a few people are using it (ie. distros don't see a need), then it will be up to you to make the changes.

I believe that this functionality is of a general nature and is needed by many, not only by myself and by the CRIU group, but by all user-level software packages, past present and future, that provide some form or another of reconstructing a Linux process.

Yes, that is why I said this needs the new option.

If the tracer does PTRACE_SYSCALL the tracee reports syscall exit _after_ gettimeofday/etc. The tracer can look at regs->orig_ax == -1 and detect that this is not syscall but vsyscall, it can look at regs->ip then (not with the patch below).

The beauty of using the x86 debug-registers,

x86 debug registers are already very scarce. Besides that userland applications know they have 4 of them available so it would also break them.

Quoted 1 line

Yes, that is why I said this needs the new option.

I do not mind new options although personally I do not find them meaningful
for an already deprecated ABI compatibility-only issue.

Quoted 4 lines

If the tracer does PTRACE_SYSCALL the tracee reports syscall exit _after_ gettimeofday/etc. The tracer can look at regs->orig_ax == -1 and detect that this is not syscall but vsyscall, it can look at regs->ip then (not with the patch below).

I believe applications just call PTRACE_SYSCALL twice, without checking orig_eax. At least strace and its TCB_INSYSCALL looks so.

Quoted 1 line · On Mon, 03 Dec 2012 00:54:58 +0100, [email protected] wrote:

The beauty of using the x86 debug-registers,

x86 debug registers are already very scarce. Besides that userland applications know they have 4 of them available so it would also break them.

Regards,
Jan

Quoted 4 lines · Amnon Shiloh

Now however, that "vsyscall" was effectively replaced by vdso, it creates a new problem for me and probably for anyone else who uses some form of checkpoint/restore:

Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they seem to enjoy trying to solve the c/r problems.

Quoted 8 lines · Amnon Shiloh

Quoted 4 lines

Now however, that "vsyscall" was effectively replaced by vdso, it creates a new problem for me and probably for anyone else who uses some form of checkpoint/restore:

Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they seem to enjoy trying to solve the c/r problems.

Hi Oleg, Amnon, sorry for delay on this message. First of all, I'm not vDSO specialist but as to c/r aspect of it I've had in mind the the following scenario: we dump vDSO area either complete euther simply remember the functions addresses it provides, then on restore we replace the functions prologue with jmp instruction which would point to the vDSO entries provided us by a kernel. But again, I didn't spend much time for vDSO yet.

Cyrill

2012/11/26 Cyrill Gorcunov <[email protected]>:

Quoted 10 lines · Oleg Nesterov

Quoted 8 lines · Amnon Shiloh

Quoted 4 lines

Now however, that "vsyscall" was effectively replaced by vdso, it creates a new problem for me and probably for anyone else who uses some form of checkpoint/restore:

Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they seem to enjoy trying to solve the c/r problems.

Quoted 7 lines

Hi Oleg, Amnon, sorry for delay on this message. First of all, I'm not vDSO specialist but as to c/r aspect of it I've had in mind the the following scenario: we dump vDSO area either complete euther simply remember the functions addresses it provides, then on restore we replace the functions prologue with jmp instruction which would point to the vDSO entries provided us by a kernel. But again, I didn't spend much time for vDSO yet.

I think this approach should work. Here is a bit more details:
1. A task will be not dumped in vdso code. If a task is in vdso code, we will try to catch it again.
2. Only addresses of vdso symbols will be dumped.
3. On restore we will compare addresses of symbols. If addresses are not changes, a new vdso will be mapped instead of old one. If they are changed, a new vdso will be mapped in a free space and the old vdso will be replaced on a proxy library, where all functions are replaced on jumps to suitable functions in the new vdso.

Looks simple and does not required to hack a kernel.

Quoted 2 lines

Cyrill

You could of course keep that old code and modify only the very first instruction of each routine into a jump instruction, but then the code to which the process returns may not be compatible with the new kernel and/or hardware configuration.

Quoted 5 lines

You could of course keep that old code and modify only the very first instruction of each routine into a jump instruction, but then the code to which the process returns may not be compatible with the new kernel and/or hardware configuration.

For sure there will be some limitations but I fear we can't do that much with it. I don't expect the regular program to use sigreturn for jumping into vdso code, but I could be wrong.

Cyrill

Programmers don't (and the manual-page says they shouldn't even try) call "sigreturn" directly.

If an interrupt happens, by bad luck, to occur while the process is running vdso code, then eventually, once signal-processing is complete, "sigreturn" (issued by glibc) will take the process back to where it was before the interrupt happend, inside the vdso page.