Virtual Addressing...

[JAAman]

you need a separate stack for the kernel, so that it doesnt use the user stack (which, in the case of an exception, may be corrupt), and because the user should not have access to data which may have been stored on the stack (the information will usually be 'pop'd back off the stack, but it will still be there, and shouldnt be accessible to the user-code)

[Lprogster]

OK...

Can you outline me the whole concept of change ring level - x86 seems sooo complicated! I've been reading the intel manuals again and again...

Thanks,
Lster

[JAAman]

Can you outline me the whole concept of change ring level - x86 seems sooo complicated! I've been reading the intel manuals again and again...

ok, first you have 4 rings (though only 2 are normally used), and you have some things that can only be done in ring0, and some things to which you can assign a 'least-privilege allowed' (like soft-ints)

which ring you are in is determined by the CS.rpl and SS.rpl (reference 3A:4.5

when loading a segment discripter into a segment register, the CPU compares the rpl to the dpl, and GPFs if its higher, if the rpl is lower than CS.rpl (also called the CPL), then it compares that instead (in the case of SS, SS.rpl must always equal CS.rpl

you cannot directly transfer control to a segment with a different CPL, therefore, a special trick is required to change privileges:

to go from a lower privilege (higher CPL) to a greater privilege (lower CPL), you must use either: a callgate, a syscall instruction, or (the easiest and most common) a soft-int

when a privilege change occurs, the CPU places SS:ESP on the stack as well (since SS.RPL must equal CPL), and fetches ss0:esp0 from the TSS

to return to a lower privilege (higher CPL), you simply iret -- the CPU takes the CS off the stack, and because the new CPL is different, it also takes the SS:ESP off the stack as well



hope this helps some

[AJ]

Remember that the whole point of this is protection - you don't want user applications to be able to interfere with your kernel.

At the extreme level, this should prevent virusses from attacking the kernel. At the minimal level, it should prevent user space stack/heap overflows from overwriting kernel data.

Given the above, if a user app could simply change its CS to a PL of 0, the whole thing would be useless. That's why you have to do it all through an IRQ - the interrupt switches back to PL0 and simultaneously switches to kernel code. Your kernel then has complete control over what memory can be used by what apps.

So, if your userland code does something which would give it kernel-type privileges, you will get a GPF which your kernel can then handle and terminate the offending application. That's what the whole thing is organised around.

BTW - if you are using online versions of the Intel manuals, I strongly advise you get the free hardcopies - unless you are lucky enough to have a dual screen setup, hard copies are much nicer to use!

Cheers,
Adam

[JAAman]

BTW - if you are using online versions of the Intel manuals, I strongly advise you get the free hardcopies - unless you are lucky enough to have a dual screen setup, hard copies are much nicer to use!

i second that! i have had volume 3A in my hand as i posted each reply, it is sooo much easier to use as a reference than the PDF, or online versions

[Lprogster]

I'll order them tomorrow - they're free after all, aren't they?

Thanks,
Lster

[JAAman]

yes they are free


DS only needs to be saved if it is changed

for pure segment-based task-switching, each task will normally have its own DS selector -- with its own base and limit, so DS will need to be saved between tasks (and of course separate ring0 and ring3 DS segments...)

for page-based task-switching, you will normally have only 2 data segments 1 ring0 and 1 ring3 (both 0 based, spanning the full 4GB) (segmentation in this mode is essentially disabled -- as segment translation doesnt affect the resulting address at all), and therefore, the addresses really dont need to be saved

[Lprogster]

...

[JAAman]

no, your not setting DS to 0

i assume you were referring to this:

(both 0 based, spanning the full 4GB)

that is a zero-based, not null segment

yes using a null segment will cause a GPF, but you can set the base (in the descriptor) to zero, then all references to it will be physical=linear (essentially disabling segmentation)

[Lprogster]

No... I mean:

Code: Select all

...

[JAAman]

ya, that will cause a GPF the first time you try to access data by DS

you will need to change (or push/pop) DS when you switch rings, if you want to use a ring0 DS

if you want to use a ring0 DS (most likely you will), then you can push DS/pop DS like your doing there

but this isnt saving/restoring on task-switch, it is on ring-change (you are changing into ring0, and may want to change to use a ring0 DS)

on task-switch, you would (in a conventional page-based system) not need to change DS (or save/restore it) because (under most OSs) you will be in ring0 on both ends, and therefore using the same segment-selector (and RPL)

however, under segment-based system, you normally will adjust the segments for each task, so that they dont overlap, therefore you will need to save and restore the DS selector between tasks

[Lprogster]

Thanks,
Lster

[JAAman]

no it doesnt -- when you push DS and then POP DS, that is the DS that was in use in the code before the int was called

a ring3 data segment will work in ring0, but cannot be used for SS

therefore, for flat mode, DS doesnt have to be loaded between rings (but for any other method it does, as different selectors have access to different areas of memory)

edit:
reference: 3A:4.6

[Lprogster]

Thanks,
Lster

[Lprogster]

I am very confused!