From owner-cvs-all Wed Jan 3 22:35: 7 2001 From owner-cvs-all@FreeBSD.ORG Wed Jan 3 22:35:03 2001 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E2D8637B400; Wed, 3 Jan 2001 22:34:57 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA26644; Thu, 4 Jan 2001 17:29:15 +1100 Date: Thu, 4 Jan 2001 17:30:08 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Jake Burkholder Cc: Peter Wemm , Matt Jacob , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/isp isp.c In-Reply-To: <20010103234657.CC0B9BA7D@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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