[ros-dev] Policy question
myriachan at cox.net
Sun Jun 4 23:30:35 CEST 2006
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
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
----- Original Message -----
From: "Alex Ionescu" <ionucu at videotron.ca>
To: "ReactOS Development List" <ros-dev at 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.
>> processor's page table will already block access to kernel memory no
>> 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"
>> I asked about whether such restrictions should be copied. Pretty much
>> only thing using NtSetLdtEntries is NTVDM, and this restriction already
>> causes some DOS programs to break that would otherwise work. (Such
>> 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?
> Best regards,
> Alex Ionescu
> Ros-dev mailing list
> Ros-dev at reactos.org
More information about the Ros-dev