Date: Wed, 07 Nov 2001 08:36:19 -0800 From: Peter Wemm <peter@wemm.org> To: Doug Rabson <dfr@nlsystems.com> Cc: ia64@FreeBSD.ORG Subject: Re: Region usage Message-ID: <20011107163619.356CC39F0@overcee.netplex.com.au> In-Reply-To: <20011107094626.O549-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote:
> 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 whic
h
> > > 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.
Exactly.
> >
> > 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?
I dont know, but they plan to use the entire 61 bit address space for
the same shareable entity, ie: each process text segment was in a
single region, and the non-shareable parts were in a different one so that
there is a common 61 bit region to share between processes.
The ELF file layout is currently ideal for this if I recall correctly.
> > 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.
Yes, I've spoken about this with others. It would be bloody hard, but not
impossible. While the traditional exploit (overwrite return address) is
out of the question, it is still remotely possible that there may be some
other exploitable stack contents. An attacker would have to be exceptionally
lucky to find an overflow that was actually exploitable.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
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?20011107163619.356CC39F0>