tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: PaX MPROTECT gdb and software breakpoints

uOn Sun, 22 May 2016, Martin Husemann wrote:

On Sat, May 21, 2016 at 04:21:45PM -0400, Christos Zoulas wrote:
There are three solutions I can think of (maybe you can think of a better

1. Leave it as it is and document that people will have to paxctl +m
   the executables that they need to mprotect before they can debug
2. create a uvm_io1() and a new UVM_EXTRACT that breaks MPROTECT and
   fetches with the right mappings. I don't like that, it breaks MPROTECT
   and uvm contracts. But it has the advantage of working on already
   started process we PT_ATTACH to.
3. when process is execed and is already traced (PT_TRACE_ME), disable
   MPROTECT. This should work with processes started from gdb, but
   not attached ones. We will still need to explain that to attach
   and insert breakpoints you need to set MPROTECT off.

Tricky. I find (3) is a bit too limited, but it is the only clean way.
Like David suggested, (1) could be extended by a gdb message explaining
the issue.

(2) is evil, but may be needed. Of course we should restrict the new
path to traced processes, and maybe even limit it to root additionally?

If we go ahead with (2), could we at least have a sysctl knob to enable it (with default of Disabled)? That way, you could get the needed functionality, but only with an explicit action to acknowledge that you are breaking all the contracts...

| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at |

Home | Main Index | Thread Index | Old Index