Date: Thu, 4 Jan 2001 17:30:08 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jake Burkholder <jburkhol@home.com> Cc: Peter Wemm <peter@netplex.com.au>, Matt Jacob <mjacob@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/isp isp.c Message-ID: <Pine.BSF.4.21.0101041718160.14629-100000@besplex.bde.org> In-Reply-To: <20010103234657.CC0B9BA7D@io.yi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 Jan 2001, Jake Burkholder wrote: [Peter Wemm wrote] > > In the kernel, text is write protected for the static kernel. But we do > > something funky with the PSE 4MB pages and double map the text/data > > segments or something, I dont recall. I think it might be possible for writes > > to the text segment to slip through the data area, but I am far from sure > > about this. I would have thought we'd have discovered this by now if so. > > (Or bde would have found it :-). > I don't think it is protected at least for i386. I wrote a kld > a while ago that wrote into kernel text, and it worked ok. See my other mail about this (write protection was broken by 4MB pages and further broken by ELF). > This comment in sys/i386/i386/machdep.c:init386() might have some > thing to do with it: > > /* > * XXX text protection is temporarily (?) disabled. The limit was > * i386_btop(round_page(etext)) - 1. > */ > gdt_segs[GCODE_SEL].ssd_limit = i386_btop(0) - 1; > gdt_segs[GDATA_SEL].ssd_limit = i386_btop(0) - 1; I was confused when I wrote this comment. Write protection of text is essentially all at the page level and none at the segment level. Here it is the execute protection of the data section that is broken by setting the segment limit to the end of memory instead of to etext. However, we now need to execute code lying beyond etext for loadable modules. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0101041718160.14629-100000>