[ros-dev] Policy question

[Myria]

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 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.
>
>> 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 at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev