Lowlevel
Lowlevel => OS-Design => Thema gestartet von: T0ast3r am 08. January 2006, 16:48
-
hallo, ich hab ne frage:
ist es sinnvoll ein datensegment für User und System zu machen, dann würde man sich 1. nen descriptor in der gdt ersparen, und 2. die ständige trennung von User und System data Segment ersparen
also was meint ihr?
ps: kennt ihr einen kleinen schnellen c++ compiler? i. e. den nasm
-
Laut den Intel Manuals hängt das Privileglevel von CS und SS ab, ich weiß zwar nicht genau auswendig, wie das von SS abhängt, aber ich würde vorsichtshalber mal einen eigenen Descriptor für jede Privilegstufe anlegen, der eine Eintrag in die GDT schmerzt ja auch nicht.
-
huhuhu...
also was ich bis jetzt gelesen hab spielt nur CS eine Rolle, denn PL von CS ist CPL fürn ausgeführten code.
hmmmmm, ich glaub der stack ist bei mir immer user data segment...
huiiii....
-
hi,
jo das cpl hängt nur von CS ab. Aber du kannst mit einem cpl3 nicht einen Selector mit rpl3 der auf ein Deskriptor mit dpl0 zeigt in DS/SS/... laden.
Die Trennung von User/System Datensegment macht wohl Sinn oder etwa nicht :?: Sonst kannst ja gleich alles in cpl0 laufen lassen.
-
hi,
soweit ich weiss muss es auf alle Fälle 2 verschiedene Datensegmente geben, da SS ja immer geladen werden muss und das PL von SS muss immer gleich PL von CS sein.
mfg,
stefan
-
hmm... schade,
sonst hät ich ein user datensegment gemacht...
(denn das System kann ja trotzdem auf PL>0 zugriefen, solange es selbst CPL 0 hat)
denn der Zugriff geht nur, wenn RPL gleich oder kleiner dem PL des Segments oder descriptors ist :wink:
@bluecode: hast recht, aber wenn dann gehts umgekehrt, dann nehm ich EIN User Daten Segment, und nicht ein System Datensegment
wäre ja sonst auch unsinnig den User rauszusperren :wink:
-
Das mit dem einem Datensegment geht meines Wissens nach, weil ja nur DPL=3, der Rest ist ja 0, und wäre ja schlimm wenn denn Kernel nicht auf Userdatensegmente zugreifen könnte :)
-
dachte ich mir auch, heisst ja PL muss gleich ODER kleiner sein
-
Warum willst du eigentlich nur ein Datensegment :?: Das klingt erstmal ziemlich unsicher.
-
hi,
na ja von CPL 0 kann man zwar locker auf ein Datensegment mit PL 3 zugreifen, aber die CPU braucht ja immer ein Stacksegment in SS, und genau dieses muss die gleiche PL wie die derzeitige CPL aufweisen -> bei CPL 0 muss SS mit einem Datensegment von PL 0 geladen sein, bei CPL 3 mit einem mit PL 3 :)
genau deshalb braucht man ja beim Software-Multitasking auch ein TSS, da damit das Stacksegment (und Stackadresse) durch den Ring-wechsel übergeben werden.
mfg,
stefan
-
Und genau das gibt man im Selektor an: 0x10 = Zugriff auf Segment 2 mit CPL=0, 0x13 Zugriff auf selbes Segment mit CPL=3 ;)
-
das mit den verschiedenen Stacks ist doh um die tasks voneinander zu schützen, oder? (hät ich halt dacht^^)
bis jetzt hab ich eh immer 2 (daten) Semgentselektoren, trotzdem wäre einer bässer.
@bluecode:
WAS soll daran unsicher sein????????
Der User kann eh nicht aufs system daten zugreifen, nur das System auf User daten, wobei das system das sowieso kann. (sonst wär's ja nicht das System :wink: )
Und bei mir zeigen sowieso alle (außer TSS descr) auf Base 0 und haben ein Limit von max. (FFFF...);
so gesehen gibt's also keinen unterschied, außer dem PL.
-
ist es sinnvoll ein datensegment für User und System zu machen, dann würde man sich 1. nen descriptor in der gdt ersparen, und 2. die ständige trennung von User und System data Segment ersparen
Der User kann eh nicht aufs system daten zugreifen, nur das System auf User daten, wobei das system das sowieso kann. (sonst wär's ja nicht das System Winken )
Also zwischen diesen beiden Aussagen ist ja wohl definitiv ein Unterschied: Zuerst sagst du, du wolltest nur noch ein Segment für Kernel & User daten und beim zweiten sprichst du wieder von einem getrennten Kerneldatensegment... oder wie soll ich das verstehen :?:
[edit: Wenn User auf das Kerneldatensegment zugriff haben, das nene ich unsicher. <- Und das ist imho auch das was dein erstes Post meinte]
-
Er meint, das der Kernel eh immer auf alle Daten zugreifen kann (solange CPL < 3 ist). Der Kernel kann auch auf Kerneldaten zugreifen, wenn man einen PL3 Descriptor hat.
-
Er meint, das der Kernel eh immer auf alle Daten zugreifen kann (solange CPL < 3 ist). Der Kernel kann auch auf Kerneldaten zugreifen, wenn man einen PL3 Descriptor hat.
Natürlich, aber wenn ich nur ein Datensegment mit DPL3 für System/Kernel und User hab, dann kann logischerweise auch der User im Kerneldatensegment rumpfuschen.
[edit: zumindest hab ich so sein ausgangspost verstanden]
-
Naja, das kann man ja durch Paging verhindern.
-
Ok, stimmt daran hab ich in dem Zusammenhang nicht gedacht :oops:
-
im prinzip hast recht, jedoch ist mein mir die kernel area bei paging immer durch das U/S bit geschützt ;)