Should ReactOS copy unnecessary restrictions that Windows has?
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. 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?
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.)
Melissa
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
Uhh, it's called a disassembly and the x86 manuals. Attempting to access kernel memory through 0xC0000000 in the normal DS segment is no different to an x86 than accessing kernel memory through another segment at 0x00000000 in a custom segment whose base is 0xC0000000. Both are going to fail because the page table says those are kernel addresses. Since the default CS and DS already have the limit as FFFFFFFF, there isn't a risk from a different segment having the same values.
The only risk becomes the syscall and interrupt handlers. The first thing these do is load all the segment registers with proper values, before trying to read from memory. So these aren't an issue either. (CS and SS were already loaded by the CPU.)
It wasn't that the designers didn't think about security, it's that they thought *too much* about security. They saw a risk when there really wasn't one. They just never noticed because they didn't care - NTVDM is basically unsupported now.
Several years ago, I ran into several DOS programs that failed to run under NTVDM solely because they were creating selectors that wrapped the address space, so yes, a compatibility problem does exist.
ReactOS already allows NtCreateSection with SEC_IMAGE on an ELF file, which is much more of an extra feature than deleting an unnecessary security check.
Melissa
----- Original Message ----- From: "Alex Ionescu" ionucu@videotron.ca To: "ReactOS Development List" ros-dev@reactos.org Sent: Sunday, June 04, 2006 13:23 Subject: Re: [ros-dev] Policy question
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 _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-------- Original-Nachricht -------- Datum: Sun, 4 Jun 2006 14:30:35 -0700 Von: Myria myriachan@cox.net An: ReactOS Development List ros-dev@reactos.org Betreff: Re: [ros-dev] Policy question
Uhh, it's called a disassembly and the x86 manuals. Attempting to access kernel memory through 0xC0000000 in the normal DS segment is no different to an x86 than accessing kernel memory through another segment at 0x00000000 in a custom segment whose base is 0xC0000000. Both are going to fail because the page table says those are kernel addresses. Since the default CS and DS already have the limit as FFFFFFFF, there isn't a risk from a different segment having the same values.
This is only true for accesses from user mode. Are you sure that at no point, esp. somewhere in the APIs concerning VDMs, such a segment descriptor could be used from within the kernel?
The only risk becomes the syscall and interrupt handlers. The first thing these do is load all the segment registers with proper values, before trying to read from memory. So these aren't an issue either. (CS and SS were already loaded by the CPU.)
It wasn't that the designers didn't think about security, it's that they thought *too much* about security. They saw a risk when there really wasn't one. They just never noticed because they didn't care - NTVDM is basically unsupported now.
Several years ago, I ran into several DOS programs that failed to run under NTVDM solely because they were creating selectors that wrapped the address space, so yes, a compatibility problem does exist.
ReactOS already allows NtCreateSection with SEC_IMAGE on an ELF file, which is much more of an extra feature than deleting an unnecessary security check.
Melissa
----- Original Message ----- From: "Alex Ionescu" ionucu@videotron.ca To: "ReactOS Development List" ros-dev@reactos.org Sent: Sunday, June 04, 2006 13:23 Subject: Re: [ros-dev] Policy question
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 _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Melissa,
I have forwarded your question to David Cutler.
Best regards, Alex Ionescu
Myria wrote:
Should ReactOS copy unnecessary restrictions that Windows has?
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. 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?
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.)
Melissa
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Alex Ionescu wrote:
Melissa,
I have forwarded your question to David Cutler.
Best regards, Alex Ionescu
(or someone else in the NT team, I used the name as a catch-all. If you have any other questions you need to ask, you can use http://blogs.msdn.com/erick/default.aspx to submit any non-IP/NDA/DRM inquiries).
I will also not share the information if it cannot be shared with you. At best, you may have found an interesting bug, at worse, some internal behavior which cannot be made public.
Best regards, Alex Ionescu
-
Alex Ionescu -
Marc Schütz -
Myria