lkml.org 
[lkml]   [1996]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Securely removing the LDT restrictions (was: DOS4WG under dosemu)


On Sat, 8 Jun 1996, Jamie Lokier wrote:
>
> Linus, a patch is enclosed preceded by plenty of explanation.
>
> The idea is to securely allow LDT entries that cover any address range,
> which appears to be required by some software running under dosemu.
> Notably, DOS4/GW which is used by many popular games, and some graphics
> software using DJGPP. Disregard or use as you wish. Ta.

Disregard.

DEFINITELY.

The page table changes are ok, and I'll probably do that for 2.1
regardless for other reasons. The kernel page tables have the USER bit
set for purely historical reasons that aren't true any more.

However, the idea to just get rid of the LDT sanity check is just silly.
Just make sure _before_ the system call that the application doesn't get
the full segment it's asking for: if it's not going to use the whole
segment anyway (like you claim), then there is no reason to give it the
segment in the first place.

In short, the change to make the kernel accept bad segments simply
doesn't make sense. Rethink your needs.

> Note that without this, your emumodule hack to simply remove the LDT
> restriction for root means that anyone can hack the kernel if they can
> run dosemu. They just run the kernel-scrubbing DPMI client of their
> choice.

Also, I'd suggest people re-think the whole emumodule stuff. It seems it's
all totally broken wrt LDT handling, and it's doing the wrong things with
no regard to security of good taste.

If you want to emulate DOS so well that you have an insecure system, why
the hell do you want to have Linux in the first place?

Ok, I've told some people about this already (Hi Hans), but let me spell
it out once more for those that haven't heard my position on it before.

The emumodule does lots of things that are totally broken.

This LDT stuff, for example, is so damn STUPID, that I can't really see
why you are doing it this way in the first place.

Dosemu people GET YOUR ACT TOGETHER! Don't do something just because it
fixes some silly problem you have, THINK about it first! Are you all
microsoft programmers?

For example, the mapping of the kernel LDT into user space with the
emumodule stuff. That is so stupid that it makes a grown man cry..

The _real_ way to handle this is that your DPMI stuff does something like
this when a program asks for a new segment:

- cache the LDT in USER space. Don't ask the kernel to do it for you:
you know what you want the LDT to contain, so _you_ should keep track
of the read-only segment descriptor table. The kernel keeps track of
it's own version of the LDT, and you shouldn't mess with that. Judicious
use of "mmap/mprotect/shmem" recommended to change your local cached
copy while still make it read-only to the DPMI client.

- do the kernel "set_ldt()" system call, and modify the parameters to be
safe _first_ so that it works with the kernel even though the kernel
checks that your parameters make sense). If you want to, you can use
the "unsafe" version in your local LDT cache (the one that the kernel
doesn't need to know anything about), so if the program then checks
what the LDT looks like it thinks it got the same segment it asked for
(but in _real_ life the kernel has the "safe" version).

Note, the above needs _no_ kernel support, and no emumodule braindamage.

In short, if you want to map in the LDT into user space, do it by hand.
Don't go crying for the kernel to do it - you have complete control over
the LDT anyway, so it doesn't make sense to have the kernel map in the
LDT read-only into user space because that would be just telling you
something you know already. You can create the user mapping by hand in
the same routine that does the kernel system call.

Linus


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.108 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site