Date: Wed, 7 Nov 2001 09:51:11 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Peter Wemm <peter@wemm.org> Cc: <ia64@FreeBSD.ORG> Subject: Re: Region usage Message-ID: <20011107094626.O549-100000@salmon.nlsystems.com> In-Reply-To: <20011106213623.4A56439F0@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Nov 2001, Peter Wemm wrote: > Doug Rabson wrote: > > > This is not necessarily the ideal way to manage virtual addresses on ia64. > > For one thing, there are a limited number of possible address spaces which > > can be supported concurrently (itanium allows 2^18, the maximum that any > > implementation will allow is 2^24). Also, the default configuration for > > ld(1) forces the use of two regions (one for text, one for data) and we > > use a third for stack. This is pretty wasteful and leaves only two > > regions free for address space sharing. > > > > I can't see any real benefit for using more than one region for most > > programs. I think that probably the text section should default to region > > zero, offset maxpagesize (pick a value for this, 64k?) with the data > > section following in the natural way and the stack starting at the end of > > region zero. Does anyone know why the GNU folks chose to put the data > > sections in a different region from the text sections? > > I believe the reason is that TLB's are supposedly tagged by region, and > that if you have two processes using the same region for the text section, > then they share the tlb's. A context switch between two processes using > the same shared region for (say) text space means you get to avoid lots of > flushing. Not quite. The TLB's are tagged by 'region identifier' which is a number that represents a unique address space. The only way that two processes could share TLBs would be the region level, i.e. they would need to share the entire 61bit region. > > Intel are funding a research project to add region awareness to Linux to > make better use of this. This should be quite a lot of entertainment to > fit it in the Linux VM system. It will be interesting to see what kind of apis they come up with. I certainly don't want to be the one to hammer this into their VM though. Come to think of it they have changed VM systems recently (several times AFAIK) so perhaps its more flexible now? > > For what its worth, we probably could put the stack in the top end of the > data segment region. I dont recall what granularity execute attributes > run at.. are they per-region or per-page? The register stack engine > deflates most of the security implications of stack buffer overflows > but it would still be nice to have a non-executable stack. All these attributes are per-page so we could certainly make the stack non-executable. It would be bloody hard (I hesitate to say impossible) to write a stack overflow exploit for ia64 though. The return address is nowhere near the stack. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011107094626.O549-100000>