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. >
Attachment:
signature.asc
Description: OpenPGP digital signature