Autor Thema: Sysenter vs. Interrupts  (Gelesen 4347 mal)

AGGROStar1991

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« am: 13. March 2010, 12:17 »
Ich bin nun an einem Punkt wo ich für mein OS(soll übrigens idealer weise ein Exokernel werden, nur so btw) Syscalls implementieren will und mir stellt sich eine Frage: Warum zum geier nutzen so viele Betriebssysteme Interrupts als API anstatt die Funktion Sysenter? Bei der 2. Seh ich persöhnlich nur Vorteile,ausser vllt das das nur auf neueren Prozessoren funzelt.


mfg
« Letzte Änderung: 13. March 2010, 12:19 von AGGROStar1991 »

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 13. March 2010, 12:24 »
Wenn ich raten soll: Manche wegen der Kompatibilität, einige mehr weil man Interrupts sowieso schon braucht und der Syscall quasi als Nebenprodukt dabei abfällt und der große Rest, weil alle Tutorials es so machen. ;)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

AGGROStar1991

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 13. March 2010, 12:28 »
also grad das letzte halte ich für ne schlüssige erklärung xD
sollte man vllt mal in die tuts aufnehmen das es auch sysenter gibt^^

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 13. March 2010, 12:34 »
Eine Zeit lang waren hier im Forum auch Call Gates große Mode. Darüber redet im Moment auch keiner mehr. Müssen wir jetzt alle Tutorials darauf umbauen, dass mindestens drei verschiedene Syscallmechanismen unterstützt werden? ;)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

AGGROStar1991

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 13. March 2010, 12:59 »
nönö war eig eher ne scherzhafte parodie darauf wie einfach man mit medien alle beeinflussen kann xD

 :P

mfg

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 13. March 2010, 13:31 »
Pssst... Unsere Tuts sind doch von vorne bis hinten voll mit Propaganda! :-D
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

AGGROStar1991

  • Beiträge: 29
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 13. March 2010, 14:47 »
mist nu werdet ihr mich töten weil ich euer dunkles geheimnis kenne, oder? xD


mfg

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 13. March 2010, 15:23 »
Hallo,


sysenter funktioniert nur auf Intel-CPUs richtig, AMD hat was eigenes (eigentlich das selbe nur mit nem anderen OpCode), insofern ist das Argument mit der Kompatibilität schon recht wichtig.
Auf allen anderen relevanten CPU-Architekturen gibt es sowas von Anfang an, nur x86 brauchte mehrere Jahrzehnte dafür und dann auch noch mit 2 inkompatiblen Wegen.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 26. March 2010, 17:12 »
Hallo,


.... und dann auch noch mit 2 inkompatiblen Wegen.
Ich hab dazu noch was interessantes gefunden http://www.agner.org/optimize/blog/read.php?i=25, bitte denkt darüber mal nach!!
Ein OS arbeitet an unterster Front und ist somit von diesem Problem auch sehr direkt betroffen, der Syscall-Mechanismus ist da nur die Spitze des Eisbergs.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

FlashBurn

  • Beiträge: 844
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 31. March 2010, 22:55 »
Sysenter hat noch den Nachteil, dass das User ESP Register nicht gespeichert wird, das muss man selber machen (bevor sysenter ausgeführt wird) und da kann es zu Problemen kommen, weil man dann auch testen muss, ob die Page wo der Stack drin liegen soll auch wirklich ne User-Page ist und ob sie wirklich geladen ist. Ein weiterer Nachteil (auch von Syscall - AMDs Variante) ist das die Rückgabe eines 64bit Wertes nicht mehr Standardkonform gelöst werden kann, da das EDX Register bereits anders verwendet wird.

Ansonsten profitieren gerade Programme die oft die Syscalls aufrufen davon.

XanClic

  • Beiträge: 261
    • Profil anzeigen
    • github
Gespeichert
« Antwort #10 am: 31. March 2010, 23:52 »
Ich weiß nicht, was das Problem mit 64-Bit-Werten ist. Ich kann doch eax und ebx nutzen? Ich persönlich würde das sowieso in einen Assemblerstub auslagern, der dann ja ebx sichern kann und am Ende ebx nach edx schiebt.

FlashBurn

  • Beiträge: 844
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 01. April 2010, 19:53 »
Zitat von: XanClic
Ich weiß nicht, was das Problem mit 64-Bit-Werten ist. Ich kann doch eax und ebx nutzen? Ich persönlich würde das sowieso in einen Assemblerstub auslagern, der dann ja ebx sichern kann und am Ende ebx nach edx schiebt.
Da gebe ich dir recht. Im Moment habe ich meine Syscalls aber soweit optimiert das ich nicht in einen Stub zurückkehre sondern direkt an die Instruktion die nach dem Call kommt. Aber ich habe schon geplant dies zu ändern, da ich mir damit einige Fehler in den Kernel holen kann und das möchte ich vermeiden. Ich meine ganz konkret, das er als Rücksprung Adresse ne falsche angibt und ich dann ne Exception im Kernel bekomme, was weniger schön. Springe ich zu nem Stub zurück und führe dort dann ein ret aus, dann wird die Exception im User-Mode geworfen was weniger problematisch ist und ich könnte gleichzeitig die von die beschriebene Methode zur Rückgabe von 64bit Werten nutzen.

So aber wie würdet ihr das Problem mit dem User-Stack lösen. Ich meine das der Aufrufer ne falsche Adresse im ESP stehen hat oder er einfach sysenter ohne den vom Betriebssystem bereitgestellten Stub nutzt?

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 01. April 2010, 19:59 »
Hallo,


So aber wie würdet ihr das Problem mit dem User-Stack lösen. Ich meine das der Aufrufer ne falsche Adresse im ESP stehen hat oder er einfach sysenter ohne den vom Betriebssystem bereitgestellten Stub nutzt?
Auf einen frei nutzbaren OS ist das IMHO ein ernstes Problem das im Kernel zuverlässig gelöst werden sollte.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

 

Einloggen