|
BugTraq
http://www.smashguard.org Jan 30 2004 11:34PM Hilmi Ozdoganoglu (cyprian purdue edu) (2 replies) RE: http://www.smashguard.org Feb 03 2004 12:36PM Dave Paris (dparis w3works com) (2 replies) RE: http://www.smashguard.org Feb 06 2004 08:29PM Hilmi Ozdoganoglu (cyprian purdue edu) (3 replies) Re: http://www.smashguard.org Feb 07 2004 11:44PM Crispin Cowan (crispin immunix com) (2 replies) Re: http://www.smashguard.org Apr 29 2004 09:55PM Pavel Machek (pavel ucw cz) (3 replies) Re: http://www.smashguard.org Apr 29 2004 11:24PM Crispin Cowan (crispin immunix com) (2 replies) Re: http://www.smashguard.org Feb 07 2004 03:27PM Theo de Raadt (deraadt cvs openbsd org) (1 replies) |
|
Privacy Statement |
> sensible separation of R and X bits per page, fixing a glaring and
> anomalous defect in the original 386 MMU. Many CPUs before and since had
> this feature, and it was just Intel slop in the early 1980s that
> developed an MMU (and associated instruction set) that mistakenly
> treated R and X per page as one bit.
It's going to get worse before it gets better.
At the same time that AMD is per-page X bit support to the x86
architecture, Intel is removing such capability from ARM cpus. And of
course mips cpus cannot do it. And it will be ages before x86
compatible cpus like the NSC Geode and such will have it.
So pretty much any low-power embedded device you can buy in the future
will not have such basic and simple protection.
Per-page execute permission functionality in a modern split-TLB CPU is
about 80 gates. On a non-split TLB it adds perhaps 80 gates + 20-per
line.
[ reply ]