IRC channel logs
2026-01-10.log
back to list of logs
<youpi>sobkas: you want to avoid the unshare mode <youpi>damo22: you're mixing things :) <youpi>yes, once fsgsbase is enabled, userland can change GSBASE, while the kernel gs base is in KGSBASE <youpi>but when we enter the kernel, the userland gs base is in KGSBASE, and the kernel gsbase is in GSBASE <youpi>so that's what we are supposed to set initially <youpi>since initially we are in the kernel <youpi>KGBASE is a backup, yes, but while in user land <youpi>while in kernel land, KGBASE is the backup of the user gs base <damo22>(10:07:08 AM) youpi: but when we enter the kernel, the userland gs base is in KGSBASE, and the kernel gsbase is in GSBASE <damo22>^ if that is the case, we would not need to swapgs on entering the kernel <damo22>because we have loaded it already <youpi>I mean: that happens *because* we'd use swapgs <youpi>precisely to swap user/kernel gs base <youpi>so it's user gs base in GSBASE and kernel gs base in KGSBASE while in userland, and when switching to kernel, the swapgs instructions gets the kernel gsbase in GSBASE and the user gs base in KGSBASE <youpi>and vice-versa on swiching from kernel to user <sobkas>sbuild --chroot-mode=schroot --help does the same <damo22>so at the point where pcb.c runs switch_ktss() that msr load should be putting KERNEL GS into KGSBASE <youpi>no, the user gs base, since switch_ktss' purpose is to load the user state <youpi>so that on return to userland, it'll end up in GSBASE <damo22>i think i am confused on the order of function calls <youpi>really, think about the invariants <youpi>while in user land, user gs base in GSBASE, kernel gs base in KGSBASE <youpi>that's why the names are like that <youpi>while in kernel land, it's the converse <youpi>and so we need swapgs between the two to achieve the switch <youpi>and switch_ktss is called in kernel land, so it's in KGSBASE that it should load the new user gs base <damo22>somehow i am getting a null seg in %gs when trap_from_kernel runs <youpi>if userland doesn't use, it, yes <youpi>is that really coming from the kernel? <youpi>you can try to inspect the stack by hand <youpi>looking for ip-looking addresses in it <youpi>possibly you are getting the trap because you still have some assembly code which isn't right yet <youpi>and you are simply trapping early in the user-to-kernel switch <youpi>sobkas: maybe fore the type to file <sobkas>@youpi: I tried it with change in configuration it didn't do anything <damo22>youpi: i dont think we can use the %ds reg to know if we need to swapgs, what if the user sets up a GDT the same as kernel but changes the base values? <Pellescours>youpi: damo22: in boothdr.c:226 (64bits), isn’t the "restore multiboot info" restoring it to the wrong register? <Pellescours>It’s taking the info from rbx and restoring it to rdi <damo22>Pellescours: no, the calling convention says %rdi is the first argument passed on x86_64 <damo22>Multiboot information structure is passed to the kernel by the bootloader, with a physical pointer stored in the EBX register and a magic number in the EAX register <damo22>so nothing touches rbx until it is saved to r8, and then it is passed to rdi before calling the c entry point <damo22>ive got a smp64 branch that almost works, just struggling with GS <damo22>somehow we are getting a null seg in %gs while in the kernel <Pellescours>damo22: ok, I didn’t know it was different register on x86_64 <Pellescours>when it’s null %gs in the kernel, is the value of KERNGS_BASE the one that you expect to be in GS? (Being sure it’s just a matter of swap and not an overwrite) <damo22>something is setting %gs = 0x68 which is correct, but the base address = 0x0 <damo22>GS =0068 0000000000000000 00000000 00209300 DPL=0 DS [-WA] <damo22>im guessing my swaps are out of sync <Pellescours>is the cpu you are using support swapgs instruction? <Pellescours>I don’t know if interrupts are disabled currently in this precise context <damo22>the tip commit has my changes for GS <damo22>but you can compile a 64 bit smp kernel with that <damo22>maybe another set of eyes on this will help <youpi>linux does use swapgs, so most probably qemu isn't bugged <youpi>damo22: _return_from_kernel may return to kernel, when an interrupt happens while in the kernel (e.g. trap_from_kernel), so it'd need to be a SWAPGS_EXIT_IF_NEEDED <damo22>similar behaviour with that change: <damo22>GS =0068 0000000000000000 00000000 00209300 DPL=0 DS [-WA] <damo22>#0 trap_from_kernel () at ../x86_64/locore.S:732 <youpi>what is the backtrace beyond the trap_from_kernel? <youpi>ah, you are reading the gdb backtrace, right <youpi>gnumach knows to step over the trap <youpi>but again you can inspect the stack by hand to look for ip-looking addresses <damo22>=> 0xffffffff8103dd2c <trap_from_kernel+6>: mov %gs:0xc,%ecx <damo22>it just hangs there because it cant access memory at 0xc <damo22>i think it crashed but i didnt allow it to reboot <youpi>you want to look at the context <youpi>by looking it up in the stack <damo22>it double faulted at the line im on <damo22>0xffffffff8103dd2c <trap_from_kernel+6>: 0x250c8b65 <damo22>yeah like half way down x/100x $rsp <damo22>0xffffffff810effa8 <idt+168>: 0x00000068 ... <damo22>that could explain why it faulted and didnt recover <damo22>the double_fault_stack.0 overflowed into the idt and broke things <damo22>ffffffff810e0f80 <double_fault_stack.0>: <youpi>note that you may have leftovers on the stack from previous function work <damo22>if trap_from_kernel traps again because it cant access memory 0xc, it will trap and arrive again at trap_from_kernel? <damo22>so no wonder i got a stack overflow <damo22>then it kept calling itself and eventually destroyed ktss and idt until it cant trap anymore <youpi>you can put a test in trap_from_kernel to avoid the recursion and stop immediately <youpi>(test against gs being 0, just for that debugging) <damo22>it did not stop on gs == 0 but broke again with the same overflow <damo22>ah because gs is not zero, the base address is <sobkas>Ok fix for libdrm with some changes based on @gnu_srs one <youpi>sobkas: in xf86drm.h you want to use sys/ioctl.h for __GNU__ too <youpi>ioccom.h is really for mach-specific things, normally we don't use that <youpi>if you are getting build issues without ioccom.h, please tell us which, because including ioccom.h is most probably not the right fix <youpi>actually I'll just drop the file, we don't seem to even be using it (and its definitions of IO/IOR/etc. is wrong) <youpi>that is expected: you need to #define a _IOT_drm_version etc. <youpi>to explain how the ioctl is supposed to encode the parameter <youpi>see e.g. sysdeps/gnu/net/if.h:# define _IOT_ifreq _IOT(_IOTS(char),IFNAMSIZ,_IOTS(char),16,0,0) <aculnaig>my name is Gianluca Cannata and I introduced myself in the bug-hurd mailing list <aculnaig>as I wrote by mail I would like to contribute to the Hurd project but i am beginner and I don't mind working on small and easy hacks just to get used to the codebase <aculnaig>I would like to do this: Strengthen httpfs: it should append '/' to URL automatically, it should not fallback index.html itself, etc. probably a lot more small easy issues. <aculnaig>Thank you, i will look into it and try to do my best. <gnu_srs1>sobkas: Why do you define PATH_MAX to 4096. See my patches submitted upstream! <nexussfan>PATH_MAX is not defined, right? I assume there is not a real path limit <damo22>it actually trapped at 0xffffffff8103df76 <all_intrs+34>: 0x250c8b65 <damo22>i think gs base is being reset to 0 when %gs is set to 0 and that messes up the swapping <youpi>dropped the value I had put in gsbase <damo22>i can only find one place gs is set to zero <damo22>so i reordered the seg flush to happen before loading the msr <damo22>it still gets a zero base address! <damo22>unless kgsbase is set to zero initially and then it swaps 0 into the base <damo22>and the initial value for gs might be 0 <damo22>yeah something is clearing %gs register and its wiping the gsbase