Messages in this thread |  | | Date | Sat, 8 Jun 1996 15:50:01 +0200 (MET DST) | From | Hans Lermen <> | Subject | Re: 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 to 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.
Conclusion:
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.
Agreed.
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.
Hans <lermen@fgan.de>
|  |