> Andrew Gillham <gillhaa@ghost.whirlpool.com> writes:
> 
> > If their patch just looks through the code for '0xf0, 0x0f, 0xc7, 0xc8' 
> > when exec()'ing, then what stops the malicious from reassembling the
> > sequence at runtime?
> 
> I don't know what it does...  All I see are .o files, and I don't have
> the time to investigate that...
> 
> I also don't want a trap for each instruction so the kernel can investigate
> to see if it is the sequence or not...
> 
> I really don't see how a software workaround is plausable for this sort
> of bug.
> 
> --Michael
> 
Conceivably, BSDI's patch may make it such that PTEs never have a page
simultaneously writeable and executable.  When a fault occurs for attempting
to execute a currently writeable page, the page is scanned for 0xc8c70ff0
(and the program is terminated by a signal if it is found) and then marked
as executable but not writeable and then execution is allowed to continue.
If later an attempt is made to write the page, another fault will occur and
the kernel will change the appropriate PTE to be writeable but not executable
and so forth.  Clearly, there would be a performance penalty for implementing
this, but it would not be a huge one provided that pages which are executed
are not written often, which is usually the case.  I'd like to indicate that
this is just my speculation as to how BSDI's patch operates.  I haven't seen
the source for their patch and I don't care to.  However, were I to implement
a comprehensive workaround for this problem for my favorite *nix, that's what
I would do.
-ben