On 07.05.2019 02:49, matthew green wrote:
I see. I will document in the man page that (void *)0 and (void *)1 are
special cases and they have to be set with PTRACE_REG_SET_PC()
explicitly if really intended.
Keeping allowed 0x0 in PT_CONTINUE/PT_DETACH/.. makes it harder to
distinguish between broken kernel and broken program.
the problem is you are trying to make potentially valid values
into magic values.
what's the ultimate goal here?
0x0 for Program Counter have two issues:
- it's not an unimplemented argument in the Linux kernel (and
conventionally set to 0x0)
- once it causes a breakage it's not immediately clear situation what
is culprit (debugger? kernel? broken program?)
Forbidding 0x0 makes it easier to deal with. It's like a trap and from
time to time someone is falling into it.
There was a thread by another developer about this exact case, just a
few months back.
can you use explicit signalling
instead of embedding special values? overloading values like
this leads to pain and failure.
maybe you can put this behind a sysctl -- perhaps even re-use
vm.user_va0_disable, such that the normal system will fail like
you are wanting, but it's possible to get around it if the
admin chooses.
Probably just forbidding it for vm.user_va0_disable is a good solution.
What do you think?
thanks.
.mrg.