channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=22&m=6&d=23
02:03:00 <klange> ToaruOS reached 5000 stars on Github.
02:06:00 <sbalmos> congrats
02:06:00 <klys> yeyy!
02:09:00 <sbalmos> klange: always wondered / figured... Yutani is your tongue-in-cheek callback to Wayland (really Weyland)? :D
02:10:00 <klange> yes
02:14:00 <klange> I used to have a FAQ page explaining that one :)
02:17:00 <sbalmos> yeah actually I just read the old Yutani article you had on the site. Shoot me.
03:20:00 <vai> morning all friends
08:44:00 <stephe> ih
15:28:00 <jafarlihi> How do you tell if GDT entry points to a normal descriptor or system descriptor?
15:32:00 <zid`> check the bits
15:32:00 <jafarlihi> zid`: which bits?
15:32:00 <zid`> in the descriptor
15:32:00 <jafarlihi> There are many bits in the descriptor
15:33:00 <zid`> I recommend the 'system' bits
15:33:00 <zid`> which is easy on x86 at least, because it only has two types, system and gate
15:34:00 <zid`> although it splits it into code data and system electric boogaloo deeper down for some reason, manual is weird
15:35:00 <zid`> http://shogun.rm-f.net/~zid/gdt.html
15:35:00 <bslsk05> shogun.rm-f.net: GDT Parser
15:35:00 <zid`> hit decode for some fun ^
15:35:00 <jafarlihi> zid`: Got source code of that?
15:35:00 <zid`> ..right click view source?
15:36:00 <zid`> but, it's just a copy of table 5.1 in the manual
15:45:00 <jafarlihi> How do you know if you are dealing with long mode system descriptor? You get the higher half first, how do you not interpret it just as regular descriptor?
15:47:00 <heat> L bit
15:48:00 <jafarlihi> So you first determine that it's a system descriptor by first 4 bits of access byte? It's considered system if those bits are either 0x2, 0x9, or 0xB?
16:00:00 <gog> #join ##transsmut
16:01:00 <gog> whoops
16:03:00 <j`ey> accident or advertising?
16:03:00 <gog> accident
16:05:00 <ddevault> going to do a little live stream going over some details about my kernel for a few people who were curious
16:05:00 <ddevault> probably nothing new for any seasoned kernel hackers, but if you're curious to join or offer comments: https://spacepub.space/w/aPiJQ8HdXsgHLHhd9mTwCG
16:09:00 <jafarlihi> Is there header I can include in LKM for getting shit like uint16_t?
16:11:00 <clever> jafarlihi: usually, that would be stdint.h
16:23:00 <mrvn> The kernel makes the GDT, why would it ever have any doubts about what each entry is?
16:27:00 <jafarlihi> I'm working backwards with LKM, not making a kernel
16:30:00 <radens> In an x86 boot sector with 16 bit code, is it possible to access memory above the address (1 << 20) ?
16:31:00 <radens> Alternatively, is it possible to call into the bios via eg int 0x13 from 32 bit mode?
16:31:00 <radens> I'm wasting space changing between 32 bit and 16 bit mode all the time when reading from disk
16:32:00 <mrvn> just use a bootloader, you are just wasting your time with dead legacy crap.
16:34:00 <radens> mrvn: playing code golf is kinda fun, but also I want to build and run on OS's where it's hard to install grub into shit
16:36:00 <heat> > Alternatively, is it possible to call into the bios via eg int 0x13 from 32 bit mode?
16:36:00 <heat> no
16:36:00 <heat> you have no choice
16:36:00 <mrvn> who says int 0x13 even exists?
16:37:00 <heat> don't you have unreal mode?
16:37:00 * heat doesn't know how that works
16:37:00 <radens> Ah I forgot about that
16:37:00 <heat> hmm ok that is interesting, it's basically abusing the segment caches
16:38:00 <heat> the CPU itself does a similar thing in the reset vector
16:38:00 <heat> cs base = 0xffff0000, ip = 0xfff0
16:44:00 <jafarlihi> clever: You can't include stdint.h in the LKM
16:45:00 <jafarlihi> No standard library allowed
16:45:00 <heat> u16 is your linux kernel equivalent
16:47:00 <jafarlihi> heat: What do I include for that? Or if nothing is required then how I make CoC happy with it?
16:48:00 <heat> <linux/types.h>
16:49:00 <jafarlihi> CoC doesn't give a shit about that, how do I fix it?
16:49:00 <heat> CoC?
16:51:00 <jafarlihi> Conquer of Completion lol
16:51:00 <jafarlihi> It's a vim plugin
16:53:00 <heat> i dunno
16:56:00 <GeDaMo> stdint.h is a set of compiler / platform specific typedefs
17:04:00 <heat> it's not allowed in the linux kernel
17:04:00 <heat> partly because it was using C89, partly because who supplies it depends on the platform and toolchain
17:05:00 <heat> in linux, it's the libc
17:16:00 <zid`> plus the type names are annoying so you end up defining u16 yourself anyway :P
17:16:00 <zid`> defining it as uint16_t is no different to doing it as unsigned short, it's a per arch header regardless
18:32:00 <FatAlbert> Oh, Ass dev!
19:09:00 <gorgonical> The stuff I barely understand in this kernel really frightens me and reminds me of how much some of you guys must know. Like this head.S I'm modifying has so much "magic asm" that I don't understand very well
19:10:00 <bauen1> uncommented code is nice, but magic code is just something else
19:11:00 <gorgonical> I even think I could understand it, but the art of coordinating low-level asm with linker scripts to put all the stuff in the right places is very obscure to me
19:36:00 <heat> bauen1, nice????
19:37:00 <bauen1> heat: i _could_ add /s
19:39:00 <sbalmos> void get_foo(void) // gets the foo
19:39:00 <sbalmos> gee, thanks /s
19:39:00 <j`ey> but returns void??
19:39:00 <gog> foo is a void
19:39:00 <heat> it returns the foo in a global variable, obviously
19:39:00 <sbalmos> heat: bingo!
19:39:00 <gog> lmao
19:40:00 <mrvn> void get_foo(void) // set foo to void
19:40:00 <sbalmos> extern struct foo_t* g_foo; // global Foo object
19:40:00 <heat> gFoo for bonus hungarian notation points
19:40:00 <mrvn> don't you all have: int errno; void * result;?
19:41:00 <sbalmos> heat: ah, that'd be extern struct foo_t* glphFoo; // global Foo handle
19:41:00 <sbalmos> mrvn: E_NOEXIST
19:41:00 <heat> i'm not convinced
19:42:00 <heat> can we add a GUID just so we know its unique and extendable?
19:42:00 <sbalmos> sure
19:49:00 <gog> gpFoo
20:03:00 <sbalmos> ah but is it a pointer or a long pointer?
20:03:00 <jafarlihi> Hey - I've got this LKM that prints GDT: https://github.com/jafarlihi/kernsec Now the issue is it reports 16th entry as this 0x40f50000000000 -- which means that it's a system segment but doesn't have one of the possible 3 long mode types, and both base and limit are 0. What the fuck is it?
20:03:00 <geist> sbalmos: wouldn't that be a glp?
20:04:00 <sbalmos> geist: exactly
20:04:00 <heat> jafarlihi, gdts don't have 16 entries
20:04:00 <heat> you need the size
20:04:00 <jafarlihi> size is 127
20:04:00 <jafarlihi> i loop over it all
20:04:00 <jafarlihi> 17th is just 0x0
20:05:00 <heat> I guarantee you your GDT isn't size 127
20:05:00 <\Test_User> 127 meaning 128 bytes probably
20:05:00 <geist> right, which is 16 entries. that lines up
20:05:00 <heat> correct
20:05:00 <jafarlihi> No, it means 128 entries
20:05:00 <jafarlihi> wait what
20:05:00 <geist> GDT/IDT/LDT length on x86 is always -1 for Reasons
20:05:00 <geist> and it'sin bytes, so 127 is a 16 entry GDT
20:06:00 <geist> which makes sense. there are probaby a bunch of auxillary GDT entries in linux
20:06:00 <geist> jafarlihi: it's possible it's a 32bit entry, or some task thing or whatnot
20:07:00 <geist> go to the source and decode it according to the manual. there's only one interpretation
20:07:00 <jafarlihi> you want me to find in linux kernel source where that gets populated? lol
20:07:00 <geist> the 'source' being the manual
20:07:00 <jafarlihi> what manual?
20:07:00 <geist> the intel or amd manual, take your pick
20:08:00 <geist> the AMD manual has nicer tables for GDT types, IMO
20:08:00 <jafarlihi> it doesn't fit, maybe my program is fucked
20:08:00 <geist> huh?
20:08:00 <geist> what doesn't fit what?
20:08:00 <jafarlihi> doesnt fit what you'd expect of descriptor
20:08:00 <geist> did you decode it?
20:08:00 <jafarlihi> with the lkm program yes
20:08:00 <jafarlihi> maybe its buggy is what im saying
20:08:00 <heat> the TSS is 2 descriptors long btw
20:08:00 <geist> and what type is it?
20:08:00 <jafarlihi> no type
20:08:00 <geist> it has a type, it has to
20:09:00 <geist> and yes, could be part of a two entry. what's in the 15th entry?
20:09:00 <jafarlihi> empty
20:09:00 <jafarlihi> 0x0
20:09:00 * geist shrugs
20:10:00 <geist> well, i mean, up to you. i'd just decode it manually and see what it is. with no assumptoins about what it *should* be
20:15:00 <geist> ah well i found where it's defined in the linux source if you want that
20:15:00 <geist> super easy to find
20:16:00 <jafarlihi> geist: tell me how you found it and where it is
20:16:00 <heat> https://edk2.groups.io/g/devel/message/90564?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2Ccrosvm%2C20%2C2%2C0%2C91811743 <-- if anyone is interested, there are patches to run any UEFI-compatible OS on crosvm
20:16:00 <bslsk05> edk2.groups.io: Running OVMF on crosvm
20:16:00 <geist> jafarlihi: please?
20:16:00 <jafarlihi> please?
20:17:00 <geist> https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/segment.h#L165
20:17:00 <bslsk05> github.com: linux/segment.h at master · torvalds/linux · GitHub
20:17:00 <geist> that is your 16 entries
20:17:00 <geist> for x86_64. _32 has more
20:17:00 <jafarlihi> shit
20:17:00 <jafarlihi> sheet
20:17:00 <geist> then it's fairly easy to grep around and find where those are used
20:17:00 <geist> arch/x86/kernel/cpu/common.c seems to be where it's set up and whatnot
20:18:00 <geist> so it's 'cpunode' whatever that means, but you should be able to figure that out
20:18:00 <jafarlihi> thanks
20:18:00 <heat> they align relevant gdt entries on cachelines wtf
20:20:00 <geist> ah https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/segment.h#L244 is the trick. they're doing some cheezy trick there with that GDT entry to encode the current cpu number
20:20:00 <bslsk05> github.com: linux/segment.h at master · torvalds/linux · GitHub
20:20:00 <geist> so it's entirely possible the GDT entry is intentionally invalid
20:21:00 <sbalmos> weird
20:21:00 <heat> holy shit that's pretty cool
20:21:00 <geist> yah i dont really grok that fully
20:21:00 <heat> they store it in the segment limit
20:21:00 <heat> and there's an instruction to get the segment limit, lsl
20:21:00 <heat> this is truly galaxy brain kernel programming
20:22:00 <geist> ooooh. load segment limit. i was reading it as 'left shift logical'
20:22:00 <geist> hah cute.
20:22:00 * geist head asplode
20:22:00 <geist> and it works becuse they have a separate GDT per cpu
20:23:00 <heat> yup
20:23:00 <heat> and everything is pretty much useless in the GDT apart from that and the standard segments
20:23:00 <geist> and apparently if PCID is eavailable they just store it there too
20:23:00 <geist> somehow
20:23:00 <heat> just compat stuff
20:23:00 <sbalmos> insert head into table
20:24:00 <geist> presumably they have a custom PCID per cpu
20:24:00 <sbalmos> repeatedly slam until make: sense
20:24:00 <heat> geist, where?
20:24:00 <wxwisiasdf> hello people i ported my os to or1k
20:24:00 <wxwisiasdf> finally i can use gdb
20:24:00 <heat> are you reading rdpid? rdpid does not mean read pcid
20:24:00 <heat> wxwisiasdf, cheers, love the weird architectures, keep it going
20:25:00 <wxwisiasdf> heh
20:25:00 <wxwisiasdf> multiarch os :D
20:25:00 <heat> maybe once you port your OS to 2 or 3 more architectures you can try the truly weird architecture, x86
20:25:00 <geist> heat: ah. read processor id
20:25:00 <geist> wxwisiasdf: yeah LK is ported to or1k as well. all in all it's a pretty boring arch though
20:25:00 <wxwisiasdf> oh
20:26:00 <sbalmos> and cpunode is probably named that way because of NUMA
20:27:00 <geist> sbalmos: yes it encodes the cpu number and the node number, according to the comments
20:27:00 <geist> makes sense that it's faster than rdtscp, since i think that also serializes things
20:28:00 <geist> where rdtscp is the usual canonical way to read the cpu id in one instruction
20:28:00 <geist> without a memory reference i guess, since a read from gs:offset would do it too
20:29:00 <jafarlihi> cpus have seperate GDT? how do I get them all with my LKM? just run many times and hope it schedules into every cpu at least once?
20:29:00 <geist> jafarlihi: yes and sure
20:29:00 <geist> see if you can pin the thread on a current cpu
20:29:00 <heat> smp_call_function_many
20:29:00 <geist> i have no idea whatyou're trying to *do* here, but if the intention is tor ead all the GDTs then yes
20:29:00 <geist> or that
20:29:00 <jafarlihi> i wanna make a security application that checks shit like gdt for shady stuff
20:30:00 <jafarlihi> wanna check syscalls and shit to make sure no one's hooking
20:30:00 <geist> via a kernel module. that' not shady at all
20:30:00 <heat> how do you know what's shady shit
20:30:00 <jafarlihi> save state and find changes
20:30:00 <heat> this reeks of anti virus software
20:30:00 <heat> or patch guard
20:30:00 <geist> yah
20:30:00 <geist> anyway, there ya go
20:32:00 <jafarlihi> i thought it'd be more useful than making another fucking kernel
20:33:00 <jafarlihi> there's already this: https://github.com/lkrg-org/lkrg
20:33:00 <bslsk05> lkrg-org/lkrg - Linux Kernel Runtime Guard (40 forks/229 stargazers/NOASSERTION)
20:33:00 <heat> whats the problem with another fucking kernel
20:33:00 <heat> i feel attacked
20:34:00 <sbalmos> heat: shouldn't you feel more violated?
20:34:00 <heat> no
20:34:00 <heat> just attacked
20:35:00 <jafarlihi> bro you can make all the kernels you want, just dont steal my idea
20:35:00 <heat> you stole your idea from like every anti virus vendor out there, and microsoft
20:35:00 <heat> its not your idea
21:01:00 <gog> i will make 30 kernels before bedtime
21:29:00 <gog> I'm not making any kernels before bedtime i lied
21:30:00 <gog> i have to work until bedtime basically
21:53:00 <j`ey> uh wtf happened here https://paste.gg/p/anonymous/2f5241f0e9274713bce67d2fbd85cbbd
21:53:00 <bslsk05> paste.gg: pastefile1 · paste.gg
21:55:00 <j`ey> all my memory is 0xffffffff how could that happen..
21:58:00 <j`ey> ok, I guess qemu loaded me at 0, and there's some MMIO around there and something funky happened