All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gábor Lénárt" <lgb@lgb.hu>
To: Marcin Tustin <mt500@ecs.soton.ac.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Whizzy New Feature: Paged segmented memory
Date: Sun, 6 Jan 2002 19:32:46 +0100	[thread overview]
Message-ID: <20020106183246.GA593@vega.digitel2002.hu> (raw)
In-Reply-To: <Pine.LNX.4.33.0201061408540.7398-100000@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.33.0201061408540.7398-100000@localhost.localdomain>

On Sun, Jan 06, 2002 at 02:14:30PM +0000, Marcin Tustin wrote:
> 	Any comments on how useful it would be to have paged, segmented,
> memory support for Pentium? I was thinking that by having separate
> segments for text, stack, and heap, buffer overrun exploits would be
> eliminated (I'm aware that this would require GCC patching as well).
> 	Obviously, I'm thinking that I (and any similar fools I could rope
> in) would try this (Probably delivering for a kernel at least a year out
> of date by the time we had a patch).

It would break everything. Nowdays, Linux (and most OSes afaik) uses a
'flat' memory modell, well at least from the point of view of a process.
This will cause that you can address any part of process memory with a
single offset (it's another question that paging may deny some access). If
you create costum separated segments (with the right limit) for stack, code
and data, you won't address the address space of the process with a single
offset. You will also need segment registers to choose the right selector
which points to the descriptor table. Imho this would break almost anything.

And more: buffer overrun exploits WON'T BE eliminated entirely: let's
inmagine, that you have a char p[40]. If you don't check the data size eg
read to that place it will overwrite memory areas after p. Well, writing a
buffer overrun exploit may be harder but it would not be impossible. By the
way, non-executable stack kernel patches (like Solar Designer's one) made
the stack non-executable too, but that is not a whole solution as well, of
course (and see the problems of that kind of patches, eg gcc trampolines -
or whatever, I can't remember - and so on).

- Gabor

  reply	other threads:[~2002-01-06 18:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-06 14:14 Whizzy New Feature: Paged segmented memory Marcin Tustin
2002-01-06 18:32 ` Gábor Lénárt [this message]
2002-01-06 20:41 ` Kevin Krieser
  -- strict thread matches above, loose matches on Subject: below --
2002-01-08  3:45 Jacques Gelinas
2002-01-08  7:17 ` Anthony DeRobertis
2002-01-08 11:22   ` jtv
2002-01-08 14:05     ` Anthony DeRobertis
2002-01-08 14:14       ` Richard B. Johnson
2002-01-08 19:33         ` Anthony DeRobertis
2002-01-08 19:45           ` Richard B. Johnson
2002-01-08 17:11       ` jtv
2002-01-08 19:32         ` Anthony DeRobertis
2002-01-08 13:42 Jacques Gelinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020106183246.GA593@vega.digitel2002.hu \
    --to=lgb@lgb.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mt500@ecs.soton.ac.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.