Mail Archives: djgpp-workers/2001/08/17/11:15:08
> So I would prefer to look whether we have good DPMI server.
Agreed, I would like to see it be a bit smarter about DPMI providers.
For example, instead of checking for DOS version I'd like to do
something a little smarter.
> Is it possible to find whether descriptor is freed under WinNT.
Yes - I've found that if you get the entire quadword descriptor
that it will be returned as all zeros. But this is slow compared
to a lsl call. But if we combined it with the current NT algorithm
it might work on all platforms and be a dozen DPMI calls or so.
> As far as I tested freeing doesn't change access rights. Maybe
> looking whether we can read or write there can help. Otherwise
> it's easy for badly behaving program (furtunatelly most DJGPP
> users don't directly mess with allocating LDT descriptors) to
> run into trouble. I would prefer checking whether selector is
> actually allocated by child process instead of blindly believing
> it's using continuous interval of selectors, as it's too easy to break
> such assumption (and Micro$oft can do it at any time eve without
> breaking DPMI specs, I think)
Every DPMI I've ever seen allocates from bottom up. Each VDM
has it's own LDT - so nothing happens that you (or your children)
didn't do to you. If they were child processes, we want to clear
it out. If it's something we did (allocate 10 descriptors and
free some in the middle keeping others) it's something the libc
didn't do...
MS is on the last generation of VDM support so I don't expect any
major changes in the future. Win XP behaves very much like
NT 3.51 did. Yes, they could break it, but they've got more
important things to break, like Java :-)
So, I'm not as worried about this as you are, but I think we should
try to make it more secure.
> maybe we should add some environment variable like
> WORKAROUND_LDT_DESCRIPTOR_LEAKS=y
> to enable support of this feature (I'ts currently dangerous for
> WinNT, Win2K and Win XT, it wastes some time on other
> systems).
I would hate to add more complexity to this. I didn't see any
real problems with the original code (you convinced me that the
speed issue was small, and I can make it not measurable in a hybrid).
Let me take a stab at something hybrid before we make this complicated.
> What about this? I added test for CWSDPMI v5 (corresponding DPMI
> call doesn't work with earlier versions).
Then they slow down or upgrade. No problem.
> Also added possibility to enable or disable workaround from environment:
> SET WORKAROUND_LDT_DESCRIPTORS_LEAK={y|n}
I actually hate this, since I don't think anyone will know when to
use it. If they see a crash they'd never figure out this is the fix.
If it's not default, noone will know to enable it.
> y is default for all cases except when CWSDPMI is begin used.
> Perhaps we should think also about using some bit in
> _crt0_startup_flags
A compile time option - maybe to disable it if you are spawning and
fragmenting the LDT? I'd rather just fix it :-)
> Andris
So, the group consensus was we need to work on this more before a commit :-)
- Raw text -