Myria wrote:
Should ReactOS copy unnecessary restrictions that Windows has?
You're not an NT designer. Just because you find something "unnecessary" doesn't mean it is. Have you emailed anyone at Microsoft to verify your theory, before potentially creating a security hole?
The example I'm thinking of is NtSetLdtEntries. In Windows NT (and currently ReactOS as well), this function will not let you create an LDT entry whose limit is above the user/kernel barrier. This restriction sounds like it was made with security in mind, but it doesn't affect security.
Then I would venture to guess that the internationally recognized and distinguished engineers, professors and developers originally assigned with the NT project didn't think of security.
The processor's page table will already block access to kernel memory no matter what selector you use. After all, the default user CS and DS already have a limit of FFFFFFFF.
Should such a problem be fixed?
We don't even know if it's a problem yet. As of now, it's an assumption.
Fireball said "no, unless some 3rd party app or driver depends on them" when I asked about whether such restrictions should be copied. Pretty much the only thing using NtSetLdtEntries is NTVDM, and this restriction already causes some DOS programs to break that would otherwise work. (Such programs are usually setting selectors that wrap the address space.)
The decision was made a long time ago not to export additional APIs or provide extra functionality which would cause programs to work on ReactOS but not Windows. This creates a dangerous slippery slope. Not being compatible doesn't only mean "not having all the features", it also means "having more features". Once ROS DLLs/programs/3rd-party applications start depending on ReactOS, you break compatibility. You also start breaking the DDK license.
But even before getting to this line of thought, I ask again. Have you verified this allegation?
Melissa
Best regards, Alex Ionescu