Hi,
I'm just trying to implement an own GDT in my OS
(currently the one from GRUB is enough, but I
want to be sure not to overwrite it) and I'm
thinking about how complex this part of my OS
has to be. Of course I could make a static data
structure for four descriptors (cs, ds, ss, es,
ehrm, shouldn't there be some for fs, gs, too?).
Well of course a GDT has different functionality,
too, three sorts of call gates, but most persons
seem to prefer interrupts gates which affect the
IDT. Why? I don't see any reasons for the other
gates, and I have heard that all have (at least
nearly) the same speed.
Thanks in advance,
The Legend
How does your GDT look like?
-
J. Weeks
RE:How does your GDT look like?
>On 2002-04-09 11:55:20, The Legend wrote:
>Hi,
>
>I'm just trying to implement an own GDT in my OS
>(currently the one from GRUB is enough, but I
>want to be sure not to overwrite it) and I'm
>thinking about how complex this part of my OS
>has to be.
I can be easily handled by your memory management
code... simply don't allow access to that area
of memory (except through a select few trusted
routines to add new descriptors to the GDT if
need be).
Alternatively (and this is what I did), you can
simply make sure that your application's descriptors
do not include that memory area. No application
can access memory that isn't in a decriptor. Your
OS can still have a descriptor that has access to
_everything_, of course (if you want).
>Of course I could make a static data
>structure for four descriptors
How? Sure, you can make the data static from C's
perspective... but that doesn't garauntee that
some rouge program can't fiddle with it, though.
>(cs, ds, ss, es,
>ehrm, shouldn't there be some for fs, gs, too?).
No, not necessarily. Remember, you're not describing
decriptors on a register by register basis, but
rather a memory range and protection basis.
You could, conceviably, have only two descriptors.
One code segment (= cs) and one data segment
(= ds = ss = es = fs = gs). Granted, your stack
is now an expand up segment, and not an expand
down as some like, but it will work.
I've done this, and it works well for single
task OSs, but for any form of protection, you're
gonna want _at least_ four. Code + Data for the OS
and Code + Data for the applications. You can
get away with just two for everything _IF_ you're
using CR3 (ie, memory paging).
>Well of course a GDT has different functionality,
>too, three sorts of call gates, but most persons
>seem to prefer interrupts gates which affect the
>IDT. Why?
I'm sure a lot of people just prefer to use one
simply because its easier.
>I don't see any reasons for the other
>gates, and I have heard that all have (at least
>nearly) the same speed.
Give or take, yeah. They each perform different
operations, though (depending on the DPL, CPL, and
sometimes RPL).
Some gates allow a program to _effectively_ switch
to a higher privelege level to perform a task,
while others will deny certain privelege levels
from performing tasks.
>Thanks in advance,
No prob.
As a side note, all this stuff is described
_beautifully_ in the PC System Architecture
Series from MindShare, Inc. ("Protected Mode
Software Architecture" ISBN: 0-201-55447-X)
I know books are expensive, but this one (in my
opinion) is a must have for pmode work. It's a
great reference (just to let you know... if you're
interested... my 2 cents
.
Jeff
>Hi,
>
>I'm just trying to implement an own GDT in my OS
>(currently the one from GRUB is enough, but I
>want to be sure not to overwrite it) and I'm
>thinking about how complex this part of my OS
>has to be.
I can be easily handled by your memory management
code... simply don't allow access to that area
of memory (except through a select few trusted
routines to add new descriptors to the GDT if
need be).
Alternatively (and this is what I did), you can
simply make sure that your application's descriptors
do not include that memory area. No application
can access memory that isn't in a decriptor. Your
OS can still have a descriptor that has access to
_everything_, of course (if you want).
>Of course I could make a static data
>structure for four descriptors
How? Sure, you can make the data static from C's
perspective... but that doesn't garauntee that
some rouge program can't fiddle with it, though.
>(cs, ds, ss, es,
>ehrm, shouldn't there be some for fs, gs, too?).
No, not necessarily. Remember, you're not describing
decriptors on a register by register basis, but
rather a memory range and protection basis.
You could, conceviably, have only two descriptors.
One code segment (= cs) and one data segment
(= ds = ss = es = fs = gs). Granted, your stack
is now an expand up segment, and not an expand
down as some like, but it will work.
I've done this, and it works well for single
task OSs, but for any form of protection, you're
gonna want _at least_ four. Code + Data for the OS
and Code + Data for the applications. You can
get away with just two for everything _IF_ you're
using CR3 (ie, memory paging).
>Well of course a GDT has different functionality,
>too, three sorts of call gates, but most persons
>seem to prefer interrupts gates which affect the
>IDT. Why?
I'm sure a lot of people just prefer to use one
simply because its easier.
>I don't see any reasons for the other
>gates, and I have heard that all have (at least
>nearly) the same speed.
Give or take, yeah. They each perform different
operations, though (depending on the DPL, CPL, and
sometimes RPL).
Some gates allow a program to _effectively_ switch
to a higher privelege level to perform a task,
while others will deny certain privelege levels
from performing tasks.
>Thanks in advance,
No prob.
As a side note, all this stuff is described
_beautifully_ in the PC System Architecture
Series from MindShare, Inc. ("Protected Mode
Software Architecture" ISBN: 0-201-55447-X)
I know books are expensive, but this one (in my
opinion) is a must have for pmode work. It's a
great reference (just to let you know... if you're
interested... my 2 cents
.Jeff
-
The Legend
RE:How does your GDT look like?
>On 2002-04-09 14:50:40, J. Weeks wrote:
>>On 2002-04-09 11:55:20, The Legend wrote:
>>Hi,
>>
>>I'm just trying to implement an own GDT in my OS
>>(currently the one from GRUB is enough, but I
>>want to be sure not to overwrite it) and I'm
>>thinking about how complex this part of my OS
>>has to be.
>
>I can be easily handled by your memory management
>code... simply don't allow access to that area
>of memory (except through a select few trusted
>routines to add new descriptors to the GDT if
>need be).
>
>Alternatively (and this is what I did), you can
>simply make sure that your application's descriptors
>do not include that memory area. No application
>can access memory that isn't in a decriptor. Your
>OS can still have a descriptor that has access to
>_everything_, of course (if you want).
>
>>Of course I could make a static data
>>structure for four descriptors
>
>How? Sure, you can make the data static from C's
>perspective... but that doesn't garauntee that
>some rouge program can't fiddle with it, though.
>
>>(cs, ds, ss, es,
>>ehrm, shouldn't there be some for fs, gs, too?).
>
>No, not necessarily. Remember, you're not describing
>decriptors on a register by register basis, but
>rather a memory range and protection basis.
>
>You could, conceviably, have only two descriptors.
>One code segment (= cs) and one data segment
>(= ds = ss = es = fs = gs). Granted, your stack
>is now an expand up segment, and not an expand
>down as some like, but it will work.
Okay, then I'll create three descriptors.
>
>I've done this, and it works well for single
>task OSs, but for any form of protection, you're
>gonna want _at least_ four. Code + Data for the OS
>and Code + Data for the applications. You can
>get away with just two for everything _IF_ you're
>using CR3 (ie, memory paging).
Yes I'm going to use paging, then I don't need
less privileged descriptors as I can simply avoid
mapping protected memory into the address range
of an application, right?
>
>>Well of course a GDT has different functionality,
>>too, three sorts of call gates, but most persons
>>seem to prefer interrupts gates which affect the
>>IDT. Why?
>
>I'm sure a lot of people just prefer to use one
>simply because its easier.
Okay.
>
>>I don't see any reasons for the other
>>gates, and I have heard that all have (at least
>>nearly) the same speed.
>
>Give or take, yeah. They each perform different
>operations, though (depending on the DPL, CPL, and
>sometimes RPL).
Hmm, interrupt gates then seems a good solution
to call kernel functions, right? If not most
people won't use them.
>
>Some gates allow a program to _effectively_ switch
>to a higher privelege level to perform a task,
>while others will deny certain privelege levels
>from performing tasks.
>
>>Thanks in advance,
>
>No prob.
>
>As a side note, all this stuff is described
>_beautifully_ in the PC System Architecture
>Series from MindShare, Inc. ("Protected Mode
>Software Architecture" ISBN: 0-201-55447-X)
>
>I know books are expensive, but this one (in my
>opinion) is a must have for pmode work. It's a
>great reference (just to let you know... if you're
>interested... my 2 cents.
>
>Jeff
Okay I think I'll buy that book if I can get it.
The Legend
>>On 2002-04-09 11:55:20, The Legend wrote:
>>Hi,
>>
>>I'm just trying to implement an own GDT in my OS
>>(currently the one from GRUB is enough, but I
>>want to be sure not to overwrite it) and I'm
>>thinking about how complex this part of my OS
>>has to be.
>
>I can be easily handled by your memory management
>code... simply don't allow access to that area
>of memory (except through a select few trusted
>routines to add new descriptors to the GDT if
>need be).
>
>Alternatively (and this is what I did), you can
>simply make sure that your application's descriptors
>do not include that memory area. No application
>can access memory that isn't in a decriptor. Your
>OS can still have a descriptor that has access to
>_everything_, of course (if you want).
>
>>Of course I could make a static data
>>structure for four descriptors
>
>How? Sure, you can make the data static from C's
>perspective... but that doesn't garauntee that
>some rouge program can't fiddle with it, though.
>
>>(cs, ds, ss, es,
>>ehrm, shouldn't there be some for fs, gs, too?).
>
>No, not necessarily. Remember, you're not describing
>decriptors on a register by register basis, but
>rather a memory range and protection basis.
>
>You could, conceviably, have only two descriptors.
>One code segment (= cs) and one data segment
>(= ds = ss = es = fs = gs). Granted, your stack
>is now an expand up segment, and not an expand
>down as some like, but it will work.
Okay, then I'll create three descriptors.
>
>I've done this, and it works well for single
>task OSs, but for any form of protection, you're
>gonna want _at least_ four. Code + Data for the OS
>and Code + Data for the applications. You can
>get away with just two for everything _IF_ you're
>using CR3 (ie, memory paging).
Yes I'm going to use paging, then I don't need
less privileged descriptors as I can simply avoid
mapping protected memory into the address range
of an application, right?
>
>>Well of course a GDT has different functionality,
>>too, three sorts of call gates, but most persons
>>seem to prefer interrupts gates which affect the
>>IDT. Why?
>
>I'm sure a lot of people just prefer to use one
>simply because its easier.
Okay.
>
>>I don't see any reasons for the other
>>gates, and I have heard that all have (at least
>>nearly) the same speed.
>
>Give or take, yeah. They each perform different
>operations, though (depending on the DPL, CPL, and
>sometimes RPL).
Hmm, interrupt gates then seems a good solution
to call kernel functions, right? If not most
people won't use them.
>
>Some gates allow a program to _effectively_ switch
>to a higher privelege level to perform a task,
>while others will deny certain privelege levels
>from performing tasks.
>
>>Thanks in advance,
>
>No prob.
>
>As a side note, all this stuff is described
>_beautifully_ in the PC System Architecture
>Series from MindShare, Inc. ("Protected Mode
>Software Architecture" ISBN: 0-201-55447-X)
>
>I know books are expensive, but this one (in my
>opinion) is a must have for pmode work. It's a
>great reference (just to let you know... if you're
>interested... my 2 cents
.>
>Jeff
Okay I think I'll buy that book if I can get it.
The Legend
-
J. Weeks
RE:How does your GDT look like?
>Yes I'm going to use paging, then I don't need
>less privileged descriptors as I can simply avoid
>mapping protected memory into the address range
>of an application, right?
Exactly. If the application tries to access memory
that hasn't been explicitly mapped to it, it'll
cause a page fault.
Paging also has the added side effect of (if you
implement it this way) having every application
running, effectively, from the same address. All
your applications can _think_ their being loaded
at 0x0 (and have no comprehension of other
applications are even running).
I just like this idea, because then each application
can be handled very similarly (is that even a word?
For example, you can map a chunk of video memory
to each application at 0xF000000 if you wanted,
or map a page of OS information at 0x1000000 for
each app... stuff like that.
>Hmm, interrupt gates then seems a good solution
>to call kernel functions, right? If not most
>people won't use them.
Yeah, definitly. Linux does it with int 0x80, if
you want some sources to look at.
Another possible way is with call gates, which I
like. You can have a call gate at, for example,
0x28. So, whenever you want to access the
operating system, you make a far call to 0x28:offset,
which will initialize the call gate.
The great thing about this, is that the offset is
actually ignored, and the selector and offset
from the descriptor (0x28) are used in the call instead.
So, if you get access to that offset, you could
have any number of functions performed at 0x28.
For example:
call 0x28:0 -> allocate memory
call 0x28:1 -> deallocate memory
call 0x28:2 -> return free memory
etc...
I haven't tried this yet, but I'm pretty sure it's
possible
>Okay I think I'll buy that book if I can get it.
Yeah, it's a great pmode reference. I use it
all the time.
Jeff
>less privileged descriptors as I can simply avoid
>mapping protected memory into the address range
>of an application, right?
Exactly. If the application tries to access memory
that hasn't been explicitly mapped to it, it'll
cause a page fault.
Paging also has the added side effect of (if you
implement it this way) having every application
running, effectively, from the same address. All
your applications can _think_ their being loaded
at 0x0 (and have no comprehension of other
applications are even running).
I just like this idea, because then each application
can be handled very similarly (is that even a word?
For example, you can map a chunk of video memory
to each application at 0xF000000 if you wanted,
or map a page of OS information at 0x1000000 for
each app... stuff like that.
>Hmm, interrupt gates then seems a good solution
>to call kernel functions, right? If not most
>people won't use them.
Yeah, definitly. Linux does it with int 0x80, if
you want some sources to look at.
Another possible way is with call gates, which I
like. You can have a call gate at, for example,
0x28. So, whenever you want to access the
operating system, you make a far call to 0x28:offset,
which will initialize the call gate.
The great thing about this, is that the offset is
actually ignored, and the selector and offset
from the descriptor (0x28) are used in the call instead.
So, if you get access to that offset, you could
have any number of functions performed at 0x28.
For example:
call 0x28:0 -> allocate memory
call 0x28:1 -> deallocate memory
call 0x28:2 -> return free memory
etc...
I haven't tried this yet, but I'm pretty sure it's
possible
>Okay I think I'll buy that book if I can get it.
Yeah, it's a great pmode reference. I use it
all the time.
Jeff