[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <3F40B615.4644.E269C65@localhost>
Date: Mon, 18 Aug 2003 11:18:45 +0200
From: pageexec@...email.hu
To: bugtraq@...urityfocus.com
Subject: Re: Buffer overflow prevention
Subject: Re: Buffer overflow prevention
From: Theo de Raadt <deraadt () cvs ! openbsd ! org>
Date: 2003-08-14 21:43:10
> > It's not difficult at all on x86, but having non-overlapping Segments
> > for Code and Data/Stack would limit the virtual address space.
>
> I am not sure if you have heard of this neat technology called "shared
> libraries". Either you have never heard of them, or you are unaware
> of they work on an x86. Let me be completely blunt. What you are
> suggesting is unfeasable. Please go do some learning before making
> any more utterly ridiculous proposals.
Oh, the strong words of a strong man ;-). Seriously, you are wrong, the
segmentation based non-executable pages feature of PaX (SEGMEXEC [1]) does
exactly this, it creates separate (non-overlapping) segments for data/code
and has no problems with coping with shared libraries (the key to this is
vma mirroring [2]).
[...]
> Anyways, on an i386 you can do W^X somewhat. Not as perfectly as you
> can on cpus that have a per-page X bit...
You are wrong again, PaX provides perfect per-page non-executable pages
using segmentation (SEGMEXEC), there are no restrictions on the ordering
of data/code pages like in OpenBSD.
[...]
> This would give per-page execution stuff like we have on better cpus.
> We've not worked on this yet; it is less valuable since I think it is
> only newer Xeons and high-end AMD cpus which support this. And we've
> never found documentation for it either :)
Page 286 in [3] and section 5.6 in [4] have enough information about this
feature (and of course linux 2.4/2.6 source code).
[1] http://pageexec.virtualave.net/docs/segmexec.txt
[2] http://pageexec.virtualave.net/docs/vmmirror.txt
[3] http://www.amd.com/us-
en/assets/content_type/white_papers_and_tech_docs/26094.PDF
[4] http://www.amd.com/us-
en/assets/content_type/white_papers_and_tech_docs/24593.pdf
Powered by blists - more mailing lists