IRC Logs for #lost


2021-03-05

08:02:08 kevin joined the channel
08:12:38 tufel joined the channel
08:31:48 tufel: Huhu
08:33:30 tufel: Damit die Tastendrücke beim Pong-Spiel nicht an die Shell weitergeleitet wird habe ich jetzt diese Zeile eingebaut: https://git.tyndur.org/lowlevel/lbuilds/-/blob/master/lbuilds/sdl/1.2.14/patches/tyndur-video.patch#L245
08:34:14 tufel: Jetzt meint der Compiler, dass er keinen Pointer in den long long int variable casten möchte.
08:34:39 tufel: Ist dieser Cast gewollt?
08:37:46 XanClic joined the channel
08:50:43 kevin: Moin tufel
08:51:46 kevin: Was will er denn bei dir casten? Einen expliziten Cast sehe ich da nicht.
08:52:56 kevin: buf ist der einzige Pointer, aber der gehört doch da auch hin?
09:05:14 tufel: Anmerkung: »lio_stream_t« {alias »long long int«} erwartet, aber Argument hat Typ »io_resource_t *
09:05:36 tufel: lio_readf(stdin->res, 0, sizeof(buf), buf, LIO_REQ_FILEPOS);
09:06:02 tufel: main.c:267:22: Fehler: Übergabe des Arguments 1 von »lio_readf« wandelt eine Zahl in einen Zeiger um, ohne explizite Typkonvertierung [-Werror=int-conversion]
09:07:11 tufel: Mh
09:08:10 tufel: Joar, ist ein impliziter cast. Aber so richtig verstehe ich das ganze noch nicht
09:23:35 kevin: Oh, das sieht falsch aus, ja
09:23:44 kevin: Wieso tut das in SDL?
09:24:05 kevin: stdin->res->lio2_stream sollte das sein, glaube ich
09:28:51 tufel: Ah es tut :D Dankeschön :)
09:29:43 tufel: Mh kann mir nicht vorstellen, dass das in SDL jemals getan hat
09:53:48 kevin: SDL hat getan, das weiß ich
09:56:44 xq: key input? nope :D
09:56:53 xq: musste man auch explizit flushen
09:57:33 kevin: Hö? Ich hab doch mehr als einmal Supertux gespielt. ;-)
09:57:39 xq: hm
09:58:18 kevin: Aber frag mich nicht wieso es funktioniert hatr
09:58:27 kevin: Und nachdem man die Frage stellt, tut es sowieso nie wieder
10:00:16 xq: ich muss heute auch mal an meinem tyndur-zig-code weiterpuhlen
10:00:21 xq: jetzt, nachdem das hello world ging :D
10:05:51 kevin: Ach richtig, den Kind-beendet-RPC wollte ich ja auch noch in den Kernel verschieben...
10:05:55 xq: :D
10:23:09 tufel: Gabs eigentlich schon mal die Überlegung für ein neues Syscall-Interface?
10:31:45 kevin: Was genau meinst du damit?
10:34:04 tufel: Naja, der Ordner modules/lib/syscalls/ ist voller assemblercode. Für die AMD64-Portierung müsste das ganze neu gemacht werden.
10:34:40 tufel: Jetzt überlege ich gerade, wie man das ganze Architekturunabhängig machen kann.
10:36:26 tufel: Das einfachste wäre wahrscheinlich eine einzelne Architekturabhängige Syscall-Funktion die für jeden Syscall funktioniert.
10:39:01 xq: yep
10:39:39 tufel: Mh das würde auf eine Funktion mit einer variablen Parameterliste hinauslaufen.
10:39:54 xq: tufel: https://github.com/ziglang/zig/blob/master/lib/std/os/linux.zig
10:39:55 xq: guck mal hier
10:40:12 xq: https://github.com/ziglang/zig/blob/master/lib/std/os/linux/x86_64.zig
10:40:19 xq: https://github.com/ziglang/zig/blob/master/lib/std/os/linux/arm64.zig
10:41:10 tufel: Mh interessant verschiedene Syscallfunktionen für unterschiedliche Anzahl an übergebene Parameter
10:43:05 tufel: Wieviele Parameter kann bei Tyndur maximal an einen Syscall übergeben werden?
10:45:40 tufel: Die Anzahl an Paramter wird ja durch den Syscall bestimmt und dieser kann theoretisch beliebig viele Parameter haben.
10:45:55 kevin: Da musst du halt die Liste der tatsächlichen Syscalls anschauen
10:46:18 xq: syscall könnte ja auch einfach so aussehen:
10:46:49 xq: usize syscall(u32 name, usize const * argl, usize argc);
10:48:18 tufel: Oh, das ist eine coole idee
10:49:02 xq: frage ist, ob es sinnvoll ist
10:49:18 xq: oder ob das syscall-interface damit sowieso auf "ein pattern" eingedampt werden könnte
10:50:52 kevin: Damit machst du halt potentiell Arbeit zur Laufzeit, die du zur Compilezeit machen könntest
10:51:04 kevin: Wenn du mit argl irgendwas machen musst außer es unverändert an den Kernel weitergeben
10:51:22 xq: exakt
10:52:11 tufel: Mh ein Syscall braucht soviele CPU-Zyklen. Da kommt es ja auf paar kopiervorgänge nicht mehr drauf an :D
10:53:07 kevin: :-/
10:53:33 kevin: Das ist eh alles schon zu langsam
10:54:26 kevin: Wenn ich was ändern würde, dann wohl eher, dass Parameter in Registern übergeben werden statt über den Stack (dessen Gültigkeit man theoretisch auch erst noch prüfen müsste, was aber meines Wissens nicht getan wird)
10:54:47 tufel: Es gibt ja dieses auskommentierte Syscall-Interface: https://git.tyndur.org/lowlevel/tyndur/-/blob/master/src/kernel/src/arch/i386/syscall.c#L48
10:55:21 kevin: Die Implementierung ist ziemlich kaputt...
10:55:33 kevin: Du kannst nicht den Kernel auf einem Userspace-Stack laufen lassen
10:56:22 kevin: Also, für die Sicherheit von tyndur macht das wahrscheinlich auch schon keinen Unterschied mehr, aber theoretisch jedenfalls ist das Murks
10:57:24 tufel: Joar, das hast du recht. Sicherheitstechnisch ist das eine Katastrophe
11:01:36 tufel: Mh der Umbau des gesamten Syscall-Interfaces auf die Nutzung von CPU-Registern wäre wirklich die eleganteste Lösung. Aber das wäre ein ziemlicher Aufwand.
11:02:01 tufel: Und dann gäbs natürlich das Risko, dass dadurch nichts mehr funktioniert :D
11:03:09 tufel: Existieren eigentlich für alle Syscalls bereits tests?
13:33:04 kevin: Natürlich nicht
13:33:44 xq: wo kämen wir da hin?
13:34:03 kevin: Ich glaube, sobald du das ganze mal auf SYSCALL*()-Makros umgesellt hast, ist die Änderung auch nicht mehr besonders schwer
13:41:40 tufel: Mh bin jetzt etwas unschlüssig. Wollte eigentlich die Syscall-Funktionen über normale Funktionen realisierung und nicht über Makros
13:49:40 kevin: Makros funktionieren am direktesten, ohne dass du dich noch mit Datentypen rumärgern musst
13:49:53 kevin: Sonst musst du Pointer immer erst casten und sowas
14:03:20 tufel: Naja, man sagt ja immer das Makros böse sind
14:04:00 tufel: Aber ja, Makros wären hier auf jedenfall flexibel.
14:04:56 tufel: Mal eine andere Frage. Es gibt immer wieder Syscalls, die eine Adresse als Parameter übergeben: https://git.tyndur.org/lowlevel/tyndur/-/blob/master/src/modules/lib/syscalls/lostio.c#L415
14:05:34 tufel: Und dann auf die Adresse zugreifen und verändern: https://git.tyndur.org/lowlevel/tyndur/-/blob/master/src/kernel/src/syscalls/lostio.c#L303
14:07:35 tufel: Mh
14:10:31 tufel: Wie prüft der Kernel, ob die übergebene Adresse überhaupt gültig ist.
14:11:00 xq: wahrscheinlich: "gar nicht"
14:13:54 tufel: Joar, das glaub ich langsam auch. Zumindest find ich nichts im Kernel, was auf eine prüfung hindeutet.
14:14:35 tufel: Sicherheitstechnisch wäre das eine ziemliche Katastrophe
14:14:53 kevin: Ich glaube, irgendwo hat es ein paar TODO-Kommentare. Dann ist das doch in Ordnung, oder? *g*
14:15:15 tufel: Ah stimmt
14:15:32 tufel: Ja dann ist ja alles in Ordnung XD
14:32:37 tufel: Mh ich glaub ich schreib mir das auf meine Todo-Liste. Für die Überprüfung der übergebenen Adressen aus dem Userspace muss wahrscheinlich das Memory-Management erweitert werden.
16:19:24 tufel: Der Syscall "get_tick_count()" nutzt als einzigster Syscall zusätzlich das EDX-Register für die Ergebnisübergabe.
16:20:09 tufel: Hab jetzt einfachmal den Syscall ein wenig modifiziert. Der Benutzer übergibt jetzt einen Pointer auf eine uint64_t Variable.
16:30:51 kevin: Oder du machst einfach ein separates Makro für Syscalls ohne Parameter, aber mit 64-Bit-Rückgabewert
16:42:29 tufel: Mh was bedeutet Exception 14; Error Code = 0x4?
16:42:47 tufel: Ich glaub ich hab was grundlegendes Kaputt gemacht
16:43:59 kevin: 14 ist Page Fault
16:45:48 tufel: Mh das erklärt natürlich auch den nachfolgenden Fehler: PANIC: Stackframe von Interrupt liegt ausserhalb des Kernelstacks des aktuellen Threads. (pm_scheduler_yield() nach Thread-Wechsel?)
16:46:30 tufel: Ich glaub ich bau alles zurück und mach das mit dem Makro
16:46:35 kevin: Dann hast du wohl den Kernelstack kaputtgemacht
20:15:30 tufel joined the channel
21:26:17 Paddy joined the channel
21:27:17 SarahIsWeird joined the channel
21:27:23 SarahIsWeird: halloechen :D
21:27:46 xq: heya
21:28:56 Paddy: Moin
21:34:14 tufel: huhu
21:36:13 SarahIsWeird: na, wird hart gearbeitet? ^^
21:36:43 xq: https://random-projects.net/blog/2021-03-05-gemtext-parser.gemini
21:38:36 SarahIsWeird: oh cool! :D
21:40:26 xq: wäre ne witzige idee, für tyndur nen grafischen gemini-browser zu basteln
21:41:28 SarahIsWeird: oder gopher, da gibts glaub ich sogar noch mehr ^^
21:42:18 xq: noch, ja
21:42:24 xq: gopher könnte ich auch noch bauen, ja :D
21:42:32 xq: Kristall kann das ja (mein Gemini/Gopher/Finger-Browser)
21:43:05 SarahIsWeird: tbh, so viel weiss ich von den ganzen sachen nix lul
21:43:15 xq: guck mal hier:
21:43:15 xq: wäre ne witzige idee, für tyndur nen grafischen gemini-browser zu basteln
21:43:15 xq: oder gopher, da gibts glaub ich sogar noch mehr ^^
21:43:18 xq: doof
21:43:18 SarahIsWeird: das war alles vor meiner zeit, und heutzutage ist das alles ja eher exotisch lul
21:43:21 xq: https://kristall.random-projects.net/
21:50:11 SarahIsWeird: schau ich mir probs mal morgen an, wollte ich eh mal machen
21:52:34 xq: tu das
22:01:45 SarahIsWeird: wow, ich frag mich grade wieso mein kernel double faultet ohne dass er irgendwas davor wirft.. stichwort hardwareinterrupts remappen xd
22:03:15 Paddy: Die Definition von einem Double Fault ist, dass der erste Fault nicht funktioniert hat. Also kein Wunder, dass von dem nichts mitbekommen hat.
22:03:24 Paddy: *dass der Kernel
22:05:29 SarahIsWeird: naja klar, aber auch der qemu debug output hat keinen fault ausgespuckt
22:05:42 SarahIsWeird: sonst wuerde ich ja dort eigentlich wenigstens ne spur davon sehen
22:07:00 SarahIsWeird: und da IRQ 8 die RTC ist, passt das ^^ double fault ist auch 0x8
22:10:52 Paddy: Ah, die IRQs würde ich dann vielleicht mal remappen ;-)
22:16:14 tufel: So ich geh mal so langsam schlafen. Gute Nacht