The current solution to handle the protection fault trap is not

correct.  It breaks down if we're trying to jump through a function
pointer. The protection fault trap on i386 must be one of the most
braindead traps ever invented in the history of humankind. It doesn't
give you any information about what went wrong except the instruction
that faulted. Since the problem we're trying to deal with is a
segmentation problem, we don't get the desitination that we want to
jump to, we just get the instruction and we won't add a disassembler
to trap handling just to try to figure out what went wrong.

What we want to do is to handle this as a normal fault to let noexec
accounting in pmap_enter deal with the changes to the code
segment. Unfortunately that's impossible. We don't know the faulting
address, so we need to change how the exec accounting works. Basically
the code segment must already cover the address we want to execute
before we can fault it in.

New scheme:

 o Start with conservative code segment.

 o If we get a protection fault, go through all mappings in the process
  and find the highest executable mapping, fix up the code segment and
  record that address. If the code segment didn't change, the protection
  fault wasn't fixable - just die.

 o If the highest executable mapping is removed, just reset the code
  segment to something conservative and let the next protection fault
  deal with it.  We can't read all the vm mappings of the process from
  the pmap because of locking hell.

This should allow floating code segment whenever someone implements that.

Also, fix the pmap_protect function to behave more like the other
pmaps we have and be slightly more agressive to force more proper
protection changes.

ok:ed by various people.

0 files changed, 0 insertions, 0 deletions