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

Hi Linus,
Hi dosemu-people,

Oh dear, why are people so impatient? :-)

Well, now it is made public, I give the background info that may calm down
the discussion untill we _really_ know how to clean up things.
( what should be read: "let me the time to do my job good" )

1. On the Linux-Congress in Berlin we (Linus and me) came to an agreement
a) abandon emumodule and
b) have a minimum set of dosemu support in the kernel (just to make
emumodule superflous).
However, after 2.0.

2. Since that I'm working on a solution. It's not simple, and it's not only
the LDT stuff. So, please don't make the LDT discussion to a topic
of no-go-if-not-having-it.

The reason _why_ we tried the KERNEL_LDT in the past was that some DPMI
clients (Win31) are checking the 'accessed' bit (bit 0 in the type
field) in order to decide wether to reload some stuff or not. We were
hoping this could make the original Win31-kernel running, but
unfortunately it didn't.
Nevertheless, it made the rest running more stable, so we left the
KERNEL-LDT in. Looking at the caveats we get with that, I guess it's not
worth the trouble and I personally allready made the decision:

NO KERNEL_LDT_ALIAS in 2.1.x !!!
( Linus, if ever I promise something, then I do it ! )

3. Because 2.0 will not have dosemu-kernel support (see above), we will
be stick on emumodule for 2.0. However, it will reflect the changes
that are made for 2.1.x and be always in sync with it.

If you now see some changes in emumodule, that seem to make the sitation
worse, well, that's because we have not yet changed dosemu to reflect
the new strategies and are playing to get it somehow working.
During the 2.1.x development we will step by step dissallow access, and
then emulate the bombing accesses. As we have no 'clean interface'
for DOS and (not even) for DPMI, all dosemu development is sort of
'trial and false', making some application work by hopeing others will
then run also. You can't compare this kind of development with the
'clean' work when designing a 'fresh' system (such as Linux).
Besides the Wine-people we (the dosemu team) have the hardest job
within the Linux community.


In 2.0.x we will have emumodule (and it's odds)
in 2.1.x there will be no emumodule, but kernel support.

Because Linus and me have been able to reasonably discuss this
( yes Linus, this was the most fertile discussion I ever had), I guess
we will be able to solve the remaining problems.

On Sat, 8 Jun 1996, Linus Torvalds wrote:

> 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.


As I see it, there is not benefit from having a valid selector, but getting
an exception due to the USER bit=0 instead of getting the fault due to
having not the proper selector. So, if we handle all by exception, we do not
need valid full range selectors anyway. (but it will hurt performance a lot)

> 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.

See above. For 2.1.x emumodule will be dead.


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