[ros-dev] Policy question
schuetzm at gmx.net
Mon Jun 5 11:04:49 CEST 2006
> -------- Original-Nachricht --------
> Datum: Sun, 4 Jun 2006 14:30:35 -0700
> Von: Myria <myriachan at cox.net>
> An: ReactOS Development List <ros-dev at 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
> an x86 than accessing kernel memory through another segment at 0x00000000
> 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
> 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
> 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
> one. They just never noticed because they didn't care - NTVDM is
> unsupported now.
> Several years ago, I ran into several DOS programs that failed to run
> 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,
> 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
> >> 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
> >> 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
> Ros-dev mailing list
> Ros-dev at reactos.org
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
More information about the Ros-dev