[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS: cvs.openbsd.org: src
- To: source-changes_(_at_)_cvs_(_dot_)_openbsd_(_dot_)_org
- Subject: CVS: cvs.openbsd.org: src
- From: Artur Grabowski <art_(_at_)_cvs_(_dot_)_openbsd_(_dot_)_org>
- Date: Mon, 12 May 2003 21:49:04 -0600 (MDT)
Module name: src
Changes by: art_(_at_)_cvs_(_dot_)_openbsd_(_dot_)_org 2003/05/12 21:49:04
sys/arch/i386/i386: freebsd_machdep.c linux_machdep.c machdep.c
pmap.c svr4_machdep.c trap.c
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.
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
ok:ed by various people.