>The kernel patch makes no such compromise. As near as I can tell, it is >completely performance neutral, and largely transparent. The only compromise >is that special handling for signal delivery is required, which the kernel >patch provides. Is it possible with the Linux kernel patch to still mprotect() parts of the stack to read-write-execute? My understanding is that that isn't possible when using x86 segment descriptors (i.e., you get all or nothing) > >> Also, using segmentation pretty much guarantees that your OS cannot be >> made to run on anything other than the x86 architecture (which is >> about the worst of the bunch; no sane person would use x86 if wasn't >> for the compatibility issues). > >Other, more sane, processors provide for read & no-execute pages, so you use a >different kernel MMU mechanism to make the stack non-executable. Thus, Casper >Dik has a similar kernel enhancement for Solaris that makes the stack >non-executable. The feature I wrote as a script for Solaris 2.5.1 and before that hotpatched kernel memory and code (and disassembled SPARC instructions in /bin/sh) was later added as a feature to Solaris 2.6 Many MMUs/processors do not support this. Older SPARC (sun4/sun4c kernel arch) do not; even UltraSPARC doesn't provide MMU support; it supports non-executable pages only because it has a split TLB. When RW- pages get examined in the iTLB handler, a fault is generated. That also was added in Solaris 2.6, so my script doesn't work for UltraSPARC in 2.5/2.5.1 either. Casper
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:14:49 PDT