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=osdev&y=18&m=11&d=7
01:19:48 <klange> we should bring back the /crp directory
01:20:56 <geist> what's that?
01:21:02 <klange> the crap directory
01:21:10 <klange> from v3 unix
01:21:42 <geist> noice
01:21:47 <aalm> really
01:22:19 <aalm> mkdir ../crp
01:24:33 <aalm> now i wonder what should i link it into
01:25:02 <geist> ~/Downloads
01:25:05 <bcos_> I'm thinking something like "recycle bin"
01:25:14 <aalm> went with /sys/kern/
01:25:29 <geist> /fishbowl
01:29:20 <mischief> klange: reading tuhs? :)
01:30:12 <klange> mischief: indirectly
01:30:12 <mischief> angelo has been doing a ton of work lately to re-typeset every unix manual set
01:30:25 <mischief> apparently ken replied and said /crp was indeed "crap" :)
01:31:46 <klange> This topic (mostly the reddit source topic that led to the /crp question on TUHS) has me thinking about my directory layout
01:37:24 <klange> I have stuff in /usr/share I should probably move. I'm thinking of making /usr the place to toss third-party stuff, in package-specific directories, like I've been doing with /usr/python for a while now
01:39:40 <mischief> i like that openbsd uses /usr/local
01:41:41 <klange> I'm figuring /bin /lib and so on are first-party stuff - the core OS. /usr/${PACKAGE} is for things installed by the package manager, /usr/bin gets symlinks so you can have a simplified $PATH, /usr/local (and preferrably /usr/local/${PACKAGE} specifically) is for things you build locally (*when I get things cleaned up enough that you stand a chance of doing that)
04:51:47 <klange> yet another horrible package manager and a rushed release, but really wanted to get it in to justify bumping the minor version number... https://github.com/klange/toaruos/releases/tag/v1.8.0
07:47:56 <rakesh4545> I remember lkurusa and klange told me to write about my experience with Uefi.
11:02:25 <b3h3m0th> It's the MMU which does the page walk right? Then why does the kernel need to have page walking code?
11:04:10 <ybyourmom> The kernel doesn't have page walking code on architectures that have assisted TLB loading
11:06:10 <b3h3m0th> I'm reading this: https://www.kernel.org/doc/gorman/html/understand/understand006.html#toc20
11:06:20 <b3h3m0th> And it has code references to what looks like a page walk.
11:06:44 <lkurusa> my code has page walk to determine what physical address is mapped to a virtual address
11:06:48 <lkurusa> but it's only used a last-resort
11:07:07 <lkurusa> you don't need per se a page walk algo in your kernel i think
11:07:50 <lkurusa> it's just that doing the mapping already involves a pagewalk, so i abstracted out that part into a proper page_walk() function
11:07:59 <b3h3m0th> So if there is a TLB miss, the page walk is done by the MMU and not the kernel?
11:14:15 <b3h3m0th> lkurusa: ybyourmom: I can see page walk related code declared here: https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/pgtable.h
11:16:06 <lkurusa> b3h3m0th: depends on the architecture, but on x86 and arm, yeah it's done by the MMU
11:16:24 <b3h3m0th> I am wondering why does the kernel even have the page walk routines then :/
11:16:27 <lkurusa> look up 'assisted TLB', in that case the MMU fires an interrupt to the kernel and it requests it to do the pagewalk
11:16:30 <b3h3m0th> In the x86 folder
11:16:39 <lkurusa> b3h3m0th: could be a bunch of reasons
11:16:51 <lkurusa> fire up bootlin's elixir and see where the code is used
11:16:54 <lkurusa> that should give you an idea
11:17:08 <b3h3m0th> TLB is not for pagewalk right?
11:17:24 <lkurusa> TLB stores virtual->physical entries
11:17:29 <b3h3m0th> Did you mean assisted MMU or something?
11:17:53 <lkurusa> the way a virtual address is resolved is it's checked in the TLB first, if it has an entry, great;
11:18:03 <lkurusa> if it does not the MMU is forced to do a pagewalk to figure out the physical entry
11:18:25 <lkurusa> once the phys addr is known, the MMU stores the translation into the TLB
11:18:32 <b3h3m0th> Okay. Got it. I was specifically interested in the case where page walk is required. That is, TLB does not have a cache of the address.
11:18:39 <lkurusa> allowing an access to the same (or the same page) virtual addr to be much quicker
11:18:58 <lkurusa> note the interesting 'race condition' here
11:19:07 <lkurusa> the translation is in the TLB and you modify the paging structures
11:19:08 <b3h3m0th> Ah. Yeah, the coherence issue.
11:19:13 <lkurusa> what happens when you acccess the virt addr?
11:19:18 <lkurusa> it resolves to the old address
11:19:32 <lkurusa> make sure to always flush the TLB when modifying the paging structure
11:19:51 <b3h3m0th> Yup. Flush TLB. Say no to side channel attacks :P
11:20:06 <lkurusa> I wouldn't say this is a side channel, but yah
11:20:23 <JManGL> Do you also need an Instruction/Memory barrier after a TLB flush (on X86/64)
11:20:34 <b3h3m0th> This is not, but how to actually leak the wrong data from the tlb would involve a side channel inference.
11:20:53 <lkurusa> JManGL: I think flushing the TLB serializes, so no
11:20:54 <b3h3m0th> JManGL: I suppose that is just to prevent any speculative caching
11:21:13 <lkurusa> unless you mean a compiler barrier, which could be, not sure, depends on how you flush, etc
11:21:35 <b3h3m0th> So now, when it's a TLB miss, what is the flow of control there? What does the CPU do?
11:21:53 <lkurusa> the MMU loads %cr3 and does a page walk to find the physical address
11:22:16 <lkurusa> raising a #PF via the APIC/PIC if it's not present
11:22:26 <b3h3m0th> The CPU does not have any say in whether it can manage it's own by using soft MMU from kernel? Or MMU will get the authority there?
11:23:40 <lkurusa> i'm not sure i got that
11:23:49 <lkurusa> the kernel sets up the structures, but the mmu will walk them
11:24:07 <b3h3m0th> So you were saying about assisted walking. I assumed there is then a counter part of walking without assist from hardware.
11:24:24 <lkurusa> there are architectures where an entry missing from the TLB fires an interrupt
11:24:29 <lkurusa> ... and then the kernel can do its magic
11:24:38 <b3h3m0th> Ah okay. x86 does not support that mode?
11:24:46 <lkurusa> as far as im aware, no
11:25:27 <lkurusa> sadly, i have no experience with assisted tlb architectures, but would love to get my hands on one
11:25:29 <b3h3m0th> So whether it's 3 level page table or 4 level, all dependent on the CPU (MMU actually) and not the kernel?
11:25:42 <lkurusa> well, uh
11:25:47 <lkurusa> depends a bit on the kernel
11:25:52 <lkurusa> if you are running 32 bit mode then it's 3 level paging
11:26:02 <lkurusa> if 64 bit mode, then it's 4level (or 5 with recent intel cpus)
11:26:25 <b3h3m0th> If a 32 bit address is given, how does MMU know it's a 32 bit mode or a 64 bit mode?
11:26:42 <lkurusa> the CPU is one mode at a time
11:26:59 <b3h3m0th> MMU asks the CPU what the current mode is?
11:27:34 <lkurusa> i'd assume so, but they aren't separate chips so the information is "just there"
11:27:42 <b3h3m0th> Ah okay. Makes sense.
11:28:21 <b3h3m0th> >sadly, i have no experience with assisted tlb architectures, but would love to get my hands on one
11:28:21 <b3h3m0th> Me too. Is there any way to debug these as seamless as debugging a kernel or better, a process? :P
11:28:37 <lkurusa> i have no experience, so i don't know :-)
11:28:41 <lkurusa> but yah, i'd assume so
11:29:00 <b3h3m0th> I'm wondering if QEMU source would give insights to this.
11:29:04 <b3h3m0th> Since they are pure emulation
11:29:52 <lkurusa> if it emulates such an architecture, then it likely does
11:30:29 <b3h3m0th> It should I suppose. I mean, that's their business.
11:31:05 <b3h3m0th> Might end up getting some blue pill vulnerabilities too :P
11:31:28 <lkurusa> SPARC seems to be such an architecture where an assisted TLB is possible
11:31:36 <lkurusa> the SPARC V9 architecture allows an implementation of SPARC V9 to have no MMU, an MMU with a software-managed TLB, or an MMU with a hardware-managed TLB
11:31:59 <lkurusa> MIPS seems to _specify_ a software managed TLB
11:32:35 <lkurusa> oh it looks IA64 also had an assisted TLB
11:32:58 <b3h3m0th> Oh oh. By assisted you meant software? I thought the other way around.
11:33:05 * lkurusa wonders why that didn't make it back into x86_64
11:33:21 <lkurusa> well i'd say they aren't exactly the same
11:33:30 <lkurusa> but software managed TLB ~~ assisted TLB in my mind
11:33:40 <lkurusa> for all our purposes here :)
11:34:55 <b3h3m0th> Ah ha. My thought was in the line of "hardware assisted". As in, with Intel vt-x, we have hardware "assisted" virtualization rather than binary translation.
11:35:43 <lkurusa> Right
11:36:06 <lkurusa> assisted TLB for me meant that the TLB is in hardware, but software helps with the page walk et al
11:49:50 <mrvn> b3h3m0th: to enter 64bit mode you the long mode bit in the MMUs controll register.
11:50:44 <ybyourmom> Hardware assisted TLB loading is when the CPU walks the page tables on a page fault
11:54:15 <mrvn> iirc ARMs TLB can also be software managed to some extend.
11:54:43 <lkurusa> mrvn: ya i heard of that, but wasn't entirely sure either
11:55:00 <mrvn> But that's independent of page walking.
11:57:21 <mrvn> Reasons why you need page walking in kernel are: 1) you need to add/remove/alter entries in the page tables so you first have to find the right entry, 2) LRU has to check/set the dirty/available bit of pages, 3) COW can use a bit in the page table for faster lookups too
11:59:56 <b3h3m0th> I see.
12:01:03 <mrvn> My kernel uses only the page tables to manage the processes virt->phys mapping and memory in general. I only have a phys->process mapping as secondary structure.
12:01:09 <b3h3m0th> I have been trying to understand these and wrote a dirty code to test out something I learnt. So the CR3 should contain the physical address of the PGD which should aslo be present in the process's task_struct->mm->pgd right?
12:01:32 <mrvn> b3h3m0th: that depends on your design
12:01:52 <b3h3m0th> I'm using Ubuntu (Linux kernel) on x86_64
12:02:01 <b3h3m0th> 64 bit kernel
12:02:10 <mrvn> some people only ever have one page table, fill it on demand and clear it on every task switch.
12:02:54 <b3h3m0th> So then that means that CR3 should point to the physical address of that table right?
12:03:08 <mrvn> Basically using the page tables as second level TLB for the current process.
12:03:30 <mrvn> yes, CR3 always needs to point to the frame number of the page table.
12:03:58 <b3h3m0th> Okay. I wrote a code to memset(cr3_value, 0, 100)
12:04:07 <b3h3m0th> that should have killed the process right?
12:04:22 <b3h3m0th> I made sure that I pass the cr3 value to phys_to_virt
12:04:29 <mrvn> only if it accessed anything in the lower range of memory
12:04:31 <lkurusa> If it uses the bottom 25 entries, then yes:)
12:04:44 <mrvn> and only when you flush the TLB
12:04:47 <lkurusa> ^^^^^^^
12:04:58 <b3h3m0th> Ah okay.
12:05:07 <b3h3m0th> But a weird thing happened. My insmod process crashed.
12:05:19 <b3h3m0th> Not the process who's physical CR3 I am using.
12:05:36 <mrvn> 32bit kernel?
12:05:44 <b3h3m0th> 64
12:06:40 <mrvn> Does linux have one L4 page table per process or does it rewrite that on switch?
12:06:41 <b3h3m0th> This is my code: https://paste.linux.community/view/24b5a56b
12:08:08 <mrvn> With all the recent side channel attacks and preventions in recent month I have no idea what kind of tricks Linux plays with the page tables now but you broke something.
12:08:31 <b3h3m0th> The insmod crashing was the least expected.
12:08:31 <mrvn> Now you get to keep the pices.
12:08:41 <b3h3m0th> It only makes sense if the pgd was marked readonly
12:08:57 <b3h3m0th> The value pointed to by CR3's virtual translation can't be readonly right?
12:09:07 <mrvn> sure it can
12:09:21 <b3h3m0th> Oh. Why would page table/directory be readonly?
12:09:41 <mrvn> so you don't accidentally write to it. It doesn't even have to be mapped at all.
12:10:13 <b3h3m0th> So kernel creates page table for process during every context switch?
12:10:27 <mrvn> b3h3m0th: I don't think that is what linux does
12:10:35 <b3h3m0th> This is my crash log: https://paste.linux.community/view/1af1cf64
12:10:37 <lkurusa> it doesn't create it
12:10:43 <lkurusa> it creates it when you create the process
12:10:48 <b3h3m0th> Have a look at this: Physical: 000000003d3aa6cc
12:10:54 <b3h3m0th> It doesn't even look page aligned
12:11:02 <mrvn> because the lower bits are flags
12:11:05 <lkurusa> when you context switch from it, it just loads it form where it's stored
12:11:11 <b3h3m0th> Sorry, I meant: Virtual: 00000000d673fe35
12:11:20 <b3h3m0th> > because the lower bits are flags/
12:11:22 <b3h3m0th> Oh okay
12:11:36 <b3h3m0th> And also, the upper bits seem to be truncated
12:11:43 <b3h3m0th> Is there any structure type confusion here?
12:12:00 <mrvn> could just be in the lower 4GB
12:12:34 <lkurusa> memset(cr3_virt, 0, 100);
12:12:37 <lkurusa> you are in the kernel
12:12:45 <lkurusa> that might not do what you think it does
12:12:45 <b3h3m0th> Yeah, this is a kernel module
12:12:49 <lkurusa> do you have KPTI?
12:12:54 <b3h3m0th> I think it should
12:12:58 <b3h3m0th> Latest Ubuntu
12:13:09 <lkurusa> print the cr3_* values
12:13:29 <b3h3m0th> cr3_* ?
12:13:36 <b3h3m0th> You want me to dump the CR3 register value?
12:14:18 <b3h3m0th> But that would give the CR3 value of the process that called the kernel (insmod here) and not my target process.
12:14:19 <lkurusa> cr3_phys & cr3_virt
12:14:33 <b3h3m0th> Ah okay. It's in the log that I pasted.
12:14:47 <lkurusa> oh whoops!
12:14:56 <b3h3m0th> https://paste.linux.community/view/24b5a56b
12:15:35 <b3h3m0th> Sorry, this one: https://paste.linux.community/view/1af1cf64
12:16:25 <lkurusa> I don't think doing a memset on a virtual address is wise in the kernel
12:16:30 <Vercas> Man I wish I knew some place to discuss designing concurrent data structures. :l
12:16:30 <lkurusa> it might not be mapped at all
12:17:00 <b3h3m0th> lkurusa: But PGD page will be marked for no swapping right?
12:17:06 <lkurusa> b3h3m0th: also you have a problem, is sizeof(unsigned long) == sizeof(void *) ?
12:17:19 <lkurusa> no swapping does not imply it's mapped
12:18:17 <b3h3m0th> I did not obtain a random VA and try to memset it. I took a PA and obtained it's VA from phys_to_virt and then memset it. That should guarantee that it's mapped right?
12:18:51 <lkurusa> oh in that case it is mapped i think
12:18:58 <lkurusa> not that familiar with the lowest parts of linux mm
12:19:11 <b3h3m0th> >also you have a problem, is sizeof(unsigned long) == sizeof(void *) ?
12:19:11 <b3h3m0th> Which lines?
12:19:22 <lkurusa> when you are passing around the addresses array
12:19:41 <b3h3m0th> Ah okay, this? cr3_phys = (void *) mm->pgd;
12:19:43 <lkurusa> you store a void * into an unsigned long, and then retrieve a void *
12:19:52 <lkurusa> that doesn't work if the sizes don't match
12:20:06 <lkurusa> i think it's an ILP32 ABI in which it's broken
12:20:23 <b3h3m0th> I thought void* assumes the size of the rvalue
12:20:34 <lkurusa> s/unsigned long *addresses/void **addresses/
12:20:49 <lkurusa> s/unsigned long addresses[2]/void *addresses[2]/
12:21:13 <lkurusa> b3h3m0th: dunno, but a pointer is 64 bits on x86_64
12:21:22 <b3h3m0th> Let me try converting all void* to unsigned long *
12:21:22 <lkurusa> and an unsigned long I think is 32-bits
12:21:26 <b3h3m0th> That should do it right?
12:21:40 <lkurusa> better yet
12:21:43 <lkurusa> use uintptr_t
12:21:48 <lkurusa> that is guaranteed to fit a pointer
12:22:12 <b3h3m0th> Oh. I'll move all to uintptr_t then
12:23:36 <b3h3m0th> So uintptr_t cr3 and not uintptr_t *cr3 right?
12:23:41 <lkurusa> ya
12:24:42 <mischief> Vercas: there's a few channels on freenode that might be good.
12:24:54 <Vercas> mischief: I'm all ears. Or eyeballs.
12:25:19 <mischief> ##c, ##algorithms?
12:25:33 <mischief> or perhaps ##c-offtopic ;-)
12:26:09 <Vercas> I shall try ##algorithms first. Cheerios. :D
12:29:37 <b3h3m0th> lkurusa: sigsegv for insmod again
12:30:26 <mischief> Vercas: though it is very early in some places of the world. irc might be quiet right now
12:30:47 <b3h3m0th> How can I get the protection bets (RWX) for the page in which my target address (cr3_virt) belongs? From my module
12:30:50 <b3h3m0th> *bits
12:31:02 <b3h3m0th> Is there any direct kernel function for that?
12:31:06 <Vercas> mischief: I see, that's a good point.
12:31:15 <lkurusa> there's ought to be a pagewalk function that returns you those
12:31:19 <lkurusa> is it a GPF or a PF?
12:31:29 <b3h3m0th> I'm getting a sigsegv
12:31:39 <lkurusa> then gdb it :)
12:32:19 <b3h3m0th> general protection fault: 0000 [#1] SMP PTI
12:32:25 * lkurusa has to go for an errand, brb 40 minutes
12:32:32 <b3h3m0th> roger that
12:33:06 <b3h3m0th> >then gdb it :)
12:33:06 <b3h3m0th> I don't know the interesting functions to look for in insmod so as to filter out the noise :(
12:33:33 <b3h3m0th> and also, I suppose this runs in kernel
12:33:37 <b3h3m0th> the module_init
12:34:27 <b3h3m0th> Anyway, this looks like a valid address for PGD?
12:34:27 <b3h3m0th> Virtual: 000000005ca91494
12:34:27 <b3h3m0th> Physical: 000000004e4ec0b4
12:34:55 <b3h3m0th> I thought it was not page aligned. Let me try reading if those flags make sense.
12:36:09 <mrvn> Linux also has some code that checks the lowest 64k of memory for corruption. You destroyed any mapping for those.
12:36:56 <mrvn> b3h3m0th: I would expect all kernel structures to have virtual >= 0x80000000
12:37:06 <mrvn> 00000000
12:37:49 <mrvn> or <0 given how amd64 address space is layed out.
12:39:02 <b3h3m0th> 0x000000004e4ec0b4 & 0xFFFFFFFFFF000000 is definitely not >= 0x80000000 :(
12:39:33 <mrvn> That's physical. Might be right. But 000000005ca91494 looks like it was truncated to 32bit.
12:40:20 <mrvn> And how do you get from 000000004e4ec0b4 phys to 000000005ca91494 virt? The lower 12 bit should be identical.
12:40:58 <b3h3m0th> mrvn: cr3_phys = (void *) mm->pgd;
12:40:58 <b3h3m0th> cr3_virt = phys_to_virt(cr3_phys);
12:41:14 <b3h3m0th> Am I not supposed to use phys_to_virt?
12:41:23 <mrvn> You aren't using it right.
12:41:33 <b3h3m0th> What could possibly be wrong here? :o
12:41:44 <b3h3m0th> Oh I read "you are"
12:41:56 <b3h3m0th> What's the mistake in my usage?
12:42:12 <mrvn> read the source, understand the source, answer your own question
12:42:38 <b3h3m0th> btw. I changed void* to uintptr_t if that is what you are pointing out
12:42:39 <mrvn> The hardware doesn't allow a mapping 000000005ca91494 => 000000004e4ec0b4
12:43:54 <b3h3m0th> Why so?
12:44:23 <b3h3m0th> The lower bits are flags right?
12:44:33 <mrvn> because pages are mapped. You can't change the lower 12bit in a mapping.
12:44:51 <mrvn> The lower bits in CR3 are flags.
12:45:09 <mrvn> In a virtual address the lower bits are an offset into thew page.
12:45:11 <b3h3m0th> Ah yes. Sorry my bad.
12:46:02 <mrvn> and I have no diea if phys_to_virt wants a physical address, a page aligned address or a page frame number.
12:46:11 <mrvn> s/diea/idea/
12:46:18 <b3h3m0th> So what numbers gave away that 000000005ca91494 => 000000004e4ec0b4 is wrong translation?
12:46:22 <mrvn> Used to be phys_to_virt() would just add 0x80000000
12:46:36 <mrvn> b3h3m0th: 494 != 0b4
12:46:40 <b3h3m0th> The lower 12 bits should not be different from what?
12:47:11 <b3h3m0th> The 494 is flags data right? Why should offset (0b4) have flags data?
12:47:17 <mrvn> not in an address
12:47:56 <mrvn> Which brings me to another point. When you read out CR3 you have to mask out the flags to get the address.
12:48:21 <b3h3m0th> Okay. Got it. I'll do that.
12:48:33 <b3h3m0th> &0xFFFFFFFFFF000000 will do right?
12:48:46 <mrvn> So even if 000000005ca91494 is the right mapping that would be 1/4 way down inside the page directory.
12:49:00 <mrvn> b3h3m0th: RTFM.
12:49:08 <b3h3m0th> RTFM, roger that.
12:49:15 <klange> what are you try to do here
12:49:22 <mrvn> klange: break linux
12:49:31 <klange> clearly
12:49:42 <mrvn> and it's no breaking like he things it should :)(
12:49:53 <klange> install ponyos
12:49:56 <b3h3m0th> Yup. And eventually patch the potential hole that could possibly break linux :)
12:49:56 <klange> it'll break better
12:50:08 <mrvn> klange: more pices or sharper edges?
12:50:43 <klange> that you have no idea what you're doing makes it somewhat laughable that you think you've found a hole, but okay, sometimes people trip over things entirely by accident
12:52:07 <b3h3m0th> Well, imagine I found a hole that could corrupt the memory pointed to by mm->pgd. I am here to experiment what could happen if I can corrupt. And that part, yes, I have no idea on Earth.
12:53:02 <b3h3m0th> Apparently impact analysis requires much more knowledge than to find silly bugs.
12:56:37 <mrvn> b3h3m0th: kernel modules can corrupt everything. That's no surprise.
12:56:54 <mrvn> the linux kernel does not protect against the kernel.
12:58:10 <b3h3m0th> I am splitting into two parts. Gaining access to PGD, and overwriting PGD value for control. To avoid complexity, while writing the overwriting PGD part, I am using a kernel module to easily achieve the gaining access to PGD part.
12:58:15 <b3h3m0th> Chaining is hectic.
12:58:58 <b3h3m0th> Anyway, learning by breaking is starting to work for me. Don't you think the same?
12:59:13 <b3h3m0th> Doesn't it give you good insight when you break it?
12:59:21 <b3h3m0th> try to break it*
12:59:50 <b3h3m0th> Primarily because if I were learning by building, I would find lazy ways.
01:00:45 <klange> No, it's easy to break things. Computers are incredibly fragile.
01:00:50 <klange> I get off on making things work.
01:01:27 <b3h3m0th> When I try to break something, I see the elegance of the design pattern there. And learn a lot from the designer.
01:02:19 <klange> Well, this is neither a security research channel nor a Linux channel, so you may want to go somewhere else to break things.
01:03:12 <b3h3m0th> Well, not really security. By breaking I don't necessary mean exploiting. Dissecting things and hacking things basically. Hacking != exploiting here.
01:03:26 <klange> Breaking things is not hacking.
01:03:32 <klange> Not even in the security meaning.
01:03:38 <klange> Hacking is about /creating/.
01:03:43 <b3h3m0th> Dissecting things is one way to hacking.
01:04:00 <b3h3m0th> >Hacking is about /creating/.
01:04:00 <b3h3m0th> Not always
01:04:16 <b3h3m0th> Reverse engineering for example. Is not creating. It's learning from creators by dissecting.
01:05:20 <b3h3m0th> But I understand my current discussion could have gone a little too much off topic here.
01:05:45 <klange> Linux is not something you need to reverse-engineer.
01:06:02 <b3h3m0th> Why not?
01:06:07 <klange> Because it is open-source.
01:06:10 <b3h3m0th> Ah ha!
01:06:11 <klange> You can read the actual internals.
01:06:16 <b3h3m0th> I thought that was what you meant.
01:06:34 <b3h3m0th> Reading the internals is also kind of reverse engineering.
01:06:37 <klange> No it's not.
01:06:53 <b3h3m0th> Is not? Maybe a perspective difference.
01:07:37 <b3h3m0th> I mostly skim through the datastructure rather than Linux code. So I considered it kinda RE.
01:09:01 <b3h3m0th> But I do buy that building also forces you a lot to learn. Gotta write my own OS one of these days.
01:09:14 <klange> Come back when you've decided to do that.
01:09:21 <b3h3m0th> But I'll miss out some elegant features that I don't even know existed.
01:12:28 <bcos_> Corrupting PGD will cause CR3 to point to something that isn't a valid page directory, which will almost always cause an instant triple fault because EIP no longer points to valid code
01:26:14 * lkurusa is back
01:35:07 <mrvn> bcos_: he is writing 0 to some entries, or where he things the entries should be. And only the first 25.
01:35:42 <mrvn> problem is I'm pretty sure the virtual address is completely bogus so who knows what gets overwritten.
02:02:08 <b3h3m0th> bcos_: the things here is, instead of the process (who's pgd I am corrupting) getting a fault, my insmod who is doing the pgd corruption is getting a seg fault. But apparently I was using the addresses wrong (flags) and possibly even the functions wrong (phys_to_virt) as pointed out by the folks here.
02:03:55 <b3h3m0th> But folks, in this example: https://carteryagemann.com/pid-to-cr3.html
02:04:09 <b3h3m0th> He is not doing any masking before calling phys_to_virt. That was what I was following.
02:10:25 * bcos_ suspects pgd is a virtual address where the page directory happens to be mapped (and not a pure physical address that can be loaded into CR3)
02:11:22 <b3h3m0th> I did suspect the same but the I read this: https://www.kernel.org/doc/gorman/html/understand/understand006.html
02:11:38 <b3h3m0th> "On the x86, the process page table is loaded by copying mm_struct→pgd into the cr3 register which has the side effect of flushing the TLB."
02:12:03 <b3h3m0th> Correlating this with the fact that CR3 should contain physical address, I assumed it should be right to consider PGD to be physical.
02:12:59 <b3h3m0th> Also, otherwise this would cause a deadloop. If PGD is virtual, while setting up the PGD for a process, who will resolve the PGD to physical without a PGD in the first place.
02:13:13 <bcos_> ?
02:13:43 <b3h3m0th> If PGD is virtual, how will MMU know where to walk the page?
02:13:50 <b3h3m0th> page table*
02:14:00 <lkurusa> using the CR3 already loaded
02:14:17 <b3h3m0th> CR3 gets loaded from PGD as per the above link
02:14:34 <lkurusa> there must be a CR3 before that
02:14:44 <lkurusa> the very first CR3 is most definitely not loaded this way
02:14:49 <lkurusa> but anyway
02:14:55 <b3h3m0th> That would be the CR3 of the PID 0 I suppose
02:15:00 <b3h3m0th> in the first time.
02:15:04 <lkurusa> what matters is that %CR3 _must_ contain a *physical* address
02:15:10 <b3h3m0th> Yup
02:15:34 <b3h3m0th> And the question is, whether task_struct->mm->pgd is phys or virt
02:15:50 <b3h3m0th> There is no other way to get the CR3 of a process from the kernel, right?
02:15:53 <bcos_> a) That first guy's code is clearly treating pgd as a usable virtual address (and explictly convering it to a physical address because it wasn't a physical address to begin with)
02:16:24 <bcos_> b) CR3 should contain a physical address but the kernel probably does a lot more with the virtual address so it's faster doing a "virt_to_phys()" when loading CR3 than it is doing a "phys_to_virt()" everywhere else
02:16:53 <bcos_> c) Kenrel is mapped into all virtual address spaces and CR3 always contains something so PGD is always mapped
02:17:07 <b3h3m0th> Oh I see! I got that backwards. (for a and b)
02:17:10 <bcos_> d) phys_to_virt() is probably just a single addition
02:17:29 <lkurusa> yeah, linux identity maps from -1GB
02:17:36 <dormito> bcos_: and the first function is 1:1 and deterministic, the second is boundended only by the size/commplexity of the page table (in theory ALL pages could be mapped to the same physcal address)
02:17:39 <lkurusa> so kernel virtual addresses are linear addresses
02:18:51 <b3h3m0th> >so kernel virtual addresses are linear addresses
02:18:51 <b3h3m0th> So virt_to_phys(kernel_va) is supposed to give the same value as kernel_va?
02:19:24 <b3h3m0th> I'm not clearly understanding that.
02:19:53 <klange> no, it gives a physical address that is [in theory] kernel_va + some fixed value
02:20:13 <b3h3m0th> But then what is the purpose of a page table for a kernel then?
02:20:47 <b3h3m0th> Linux kernel uses the last process's page table or a dedicated page table (if KPTI) right?
02:21:05 <lkurusa> that `some fixed value` is PAGE_OFFSET in linux
02:21:09 <lkurusa> #define PAGE_OFFSET0xffff800000000000UL
02:22:13 <b3h3m0th> Are we talking about real mode here?
02:22:21 <lkurusa> wat
02:22:23 * klange sighs
02:22:26 <glauxosdever> o/
02:22:30 <lkurusa> how does 16 bit come into play here
02:22:32 <lkurusa> i'm confused
02:22:38 <lkurusa> heya glauxosdever
02:22:57 <b3h3m0th> > no, it gives a physical address that is [in theory] kernel_va + some fixed value
02:23:10 <b3h3m0th> If that's the case, then why we need a page table for kernel?
02:23:34 <b3h3m0th> When paging is enabled, even kernel's VA to PA has to go through a page walk right?
02:23:40 <b3h3m0th> Can't just add an offset, can we?
02:24:04 <lkurusa> so...?
02:24:09 <lkurusa> it goes through pagewalk
02:24:26 <lkurusa> _BUT_ this way you don't need to do a pagewalk in phys_to_virt/virt_to_phys in the kernel
02:24:26 <glauxosdever> I'm thinking -- should I do a throw-away (bad) OS in order to refresh some concepts before getting into the larger project (compiler + good OS)? Yay or nah?
02:24:41 <klange> make five OSes each worse than the last
02:24:41 <lkurusa> since if it's a kernel VA then you *know* the pagewalk's result already
02:24:44 <lkurusa> since it's a linear address
02:24:55 <lkurusa> glauxosdever: yay!
02:24:56 <glauxosdever> klange: It's supposed to be the opposite.. :p
02:24:59 <dormito> the page table design allows bascially any transformation (some small exceptions). A linear offset (thats a multiplue of the page size) is trivial
02:25:08 <klange> b3h3m0th: the kernel's address space is set up specifically to make things easier so that these transformations are trivial
02:25:15 <glauxosdever> lkurusa: Cool
02:25:33 <klange> glauxosdever: shit, i may have been doing things wrong all these years then...
02:25:44 <b3h3m0th> So essentially there is a single level page table for Kernel?
02:26:03 <glauxosdever> klange: Wait, is your latest OS worse than the previous?
02:26:11 <klange> well it doesn't have quake [yet]
02:26:14 <klange> and its math library sucks
02:26:24 <glauxosdever> Alright, convinced
02:26:26 <glauxosdever> :p
02:26:29 <klange> so arguably, ToaruOS 1.6x+ is worse than 1.2x
02:26:32 <lkurusa> b3h3m0th: no
02:26:40 <klange> also the compositor is slower, and the fonts look terrible
02:26:43 <lkurusa> there's a normal page table setup since you can't avoid that
02:26:48 <klange> [but you can install Cairo and Freetype and fix both of those]
02:26:54 <lkurusa> well, you can use hugepages to reduce the levels but you know..
02:27:11 <FireFly> klange: but it's all your stuff~
02:27:16 <FireFly> essentially at least
02:27:20 <b3h3m0th> But the MMU thinks it needs to do further levels of walks, right?
02:27:39 <lkurusa> b3h3m0th: if it's a hugepage then no
02:27:55 <lkurusa> but if it's a normal 4K page, then it has to exhaust all 4 (or 5) levels of paging
02:28:16 <b3h3m0th> But for x86, the page size is fixed right?
02:28:36 <klange> glauxosdever: I spent a bunch of time replacing all the third-party stuff in my OS, so on the one hand some functionality was lost, but on the other hand more stuff was implemented locally... mixed bag on whether that's better or not
02:28:50 <glauxosdever> I'd say it's better because you have more control
02:29:02 <lkurusa> b3h3m0th: No, you can have hugepages (sizes of 4MB, 1GB, etc)
02:29:13 <lkurusa> but most common page size is 4096 bytes
02:29:29 <b3h3m0th> How would the MMU know how many levels to walk then?
02:29:34 <lkurusa> RTFM
02:29:35 <lkurusa> :-)
02:29:46 <lkurusa> the entries in the paging structure tell it
02:30:57 <b3h3m0th> > #define PAGE_OFFSET0xffff800000000000UL
02:30:57 <b3h3m0th> So this means kernel always have a page directory loaded at the physical address 0xffff800000000000U I suppose.
02:31:00 <lkurusa> b3h3m0th: see intel SDM, Volume 3, Chapter 4.5
02:31:08 <lkurusa> there are some nice graphics to help explain
02:31:09 <b3h3m0th> Okay. Thanks.
02:31:29 <lkurusa> Specifically, 4-20 Vol 3A
02:31:32 <dormito> lkurusa: you lasted longer that I would have :/
02:31:33 <lkurusa> and 4-21, 4-22
02:31:51 <lkurusa> dormito: :-)
02:32:04 <lkurusa> b3h3m0th: why would it need to be loaded at physical address?
02:32:20 <lkurusa> what need to happen is that in the %CR3 the kernel uses (if KPTI) or in all %cr3's (if no KPTI)
02:32:25 <lkurusa> the address PAGE_OFFSET must be mapped
02:32:32 <lkurusa> because from onwards there is the kernel
02:32:38 <lkurusa> which again, is linearly mapped
02:32:51 <b3h3m0th> and PAGE_OFFSET is 0xffff800000000000UL hardcoded
02:33:03 <lkurusa> on x86_64 that's right
02:33:03 <b3h3m0th> Which gets loaded to CR3 means PGD is at physical address 0xffff800000000000UL
02:33:06 <lkurusa> unsure of other architectures
02:33:25 <lkurusa> that does not get loaded to CR3
02:33:27 <glauxosdever> Anyway, this OS will be mostly to see what kind of APIs will be needed, both for user programs and userspace drivers. But also how the kernel could get some things (e.g. basic graphics drivers in case native graphics drivers can't start) from a boot abstraction layer.
02:33:34 <lkurusa> There is no way you have -1GB of RAM available
02:34:03 <lkurusa> %CR3 has a physical address to a page directory (or a PML4, whatever) that *maps* -1GB(aka PAGE_OFFSET) to some value, usually 0
02:34:40 <glauxosdever> And also, it will be written in asm. I got some nostalgia from 4 years ago :p
02:34:50 <klange> glauxosdever: good luck
02:34:57 <glauxosdever> Thanks :-)
02:35:21 <lkurusa> glauxosdever: i guess welcome back to the Endless Timesink
02:35:40 <klange> i'm going to write an assembler this weekend
02:35:46 <glauxosdever> klange: Intel syntax?
02:35:54 <glauxosdever> (Assuming x86)
02:36:08 <klange> i want something reasonably gas compatible because %%REASONS%%
02:36:20 <klange> unrelatedly, I should sleep
02:36:24 <glauxosdever> I'll use nasm :-)
02:36:25 <klange> good night #osdev
02:36:28 <glauxosdever> Bye klange
02:37:25 <bcos_> klange: If you can add the data for one instruction in 1 minute, it'll only take about 6 days to create the data
02:37:26 <lkurusa> cya klange
02:37:31 <bcos_> :-)
02:38:31 <glauxosdever> bcos_: klange is more efficient than that
02:38:36 <b3h3m0th> Good night klange
02:39:12 <klange> there *is* machine-readable data on instructions for x86, you don't need to hand-code handling for each one ;
02:39:40 <klange> but anyway, I'm going to close to my screen session since y'all keep pinging me
02:39:47 <glauxosdever> klange: Pind
02:39:49 <glauxosdever> *Ping
02:39:56 * glauxosdever can't even ping properly..
02:40:37 <bcos_> Need unit tests too though!
02:40:39 <lkurusa> klange: parse it from the SDM
02:40:41 <lkurusa> https://i.imgur.com/gVCVYRl.png
02:40:42 <lkurusa> :D
02:41:26 <glauxosdever> lkurusa: That's not even under a compatible license
02:41:44 <glauxosdever> (Assuming from the Intel manuals?)
02:41:49 <lkurusa> ya it's from the SDM
02:42:05 <lkurusa> one would think intel would make this data machine readable
02:42:12 <lkurusa> or at least under a permissive license
02:45:22 <glauxosdever> Alright, so back to El-Torito. At least I have some code from this summer (originally in nasm syntax, then converted to AT&T, then improved (thank you bcos_))
02:45:27 <lkurusa> EL TORITO!
02:45:30 <glauxosdever> :D
02:45:38 <glauxosdever> So, let's convert it back to nasm syntax
02:49:59 <glauxosdever> An actual question now. IIRC, I can switch to protected mode in stage-1, then switch back to real mode to get some data from the BIOS and then again to protected mode (I won't care about UEFI now, remember this OS is a throw-away one)
02:50:04 <glauxosdever> Is that correct?
02:50:24 <glauxosdever> Are there some things I should be careful about?
02:50:29 <lkurusa> You can do that
02:50:36 <lkurusa> Have never tried it personally though
02:51:04 <glauxosdever> How do you do it?
02:52:30 <lkurusa> I think you can always go back from protected mode to real mode
02:55:57 <glauxosdever> https://wiki.osdev.org/Real_Mode#Switching_from_Protected_Mode_to_Real_Mode <- Ok, found this one
02:56:34 <lkurusa> :-)
03:07:32 <lsneff> For internships, which is more important? Doing something that looks good on a resume or doing something that you'll enjoy?
03:07:45 <JManGL> Gotta do something you enjoy
03:07:51 <JManGL> Otherwise you will not do a good job
03:08:42 <JManGL> One thing I remember Mike Acton saying, is that he liked it when someone could take one thing and see how far down the rabbit hole they could go with it. Whether they could stick with it long enough to understand every aspect of it, strengths and weaknesses.
03:08:54 <lkurusa> lsneff: what you enjoy
03:09:00 <JManGL> It doesnt have to be something big- but something with enough technical meat.
03:09:37 <lsneff> I have an offer for microsoft explore, but I don't even know what I'd be working on
03:10:02 <lkurusa> i ddg'd for microsoft explore
03:10:06 <lkurusa> internet explorer came up
03:10:13 <lkurusa> ARE YOU GOING TO WORK ON IE? :-)
03:10:22 <lsneff> hopefully not :P
03:10:44 <lkurusa> what's microsoft explore anyway?
03:11:06 <lsneff> It's an internship thing for freshman and sophmores
03:11:17 <lsneff> 4 weeks of program management and 8 weeks of software engineering
03:12:09 <lkurusa> ah it's like Google's STEP, right?
03:13:03 <lsneff> I've heard it compared to google's engineering practicum
03:13:06 <bcos_> lkurusa: Go with "looks good on resume", because quite frankly the only thing you'll be doing at 1st year uni level is making coffee ;-)
03:13:12 <bcos_> D'oh
03:13:20 <bcos_> ^ @ lsneff
03:13:49 <lsneff> For the other two offer/verbal-offers I have, I'd be working on compiler stuff
03:14:35 <lkurusa> bcos_: i got lucky and went for both after my freshman year
03:14:44 <JManGL> I would go with Microsoft if you are good at making contacts. You will meet a lot of people who will be VERY useful to know.
03:14:53 <lsneff> Actually, on of them said they'd match any competing offers
03:14:59 <lkurusa> JManGL: +1,000
03:15:00 <lsneff> Yeah, that's what people keep telling me
03:15:16 <lkurusa> Network is your net worth
03:15:20 <lkurusa> cliche, but true to some extent
03:15:35 <JManGL> Where would you be doing you internship?
03:15:36 <JManGL> Seattle?
03:15:47 <lsneff> microsoft in seattle, yeah
03:15:49 <JManGL> I know a few folk at Thames Valley Park in England
03:15:50 <JManGL> Ah right
03:15:51 <lsneff> the others are in sf
03:15:55 <JManGL> I don't really know anyone out there
03:16:03 <lkurusa> if you don't like networking, go for the compiler stuff imo
03:16:08 <JManGL> But Thames Vallery is a really cool campus
03:16:11 <lkurusa> chances are there are great people working on that, too
03:16:13 <JManGL> I imagine Seattle is even better
03:16:34 <lkurusa> Seattle is a nice town
03:16:54 <lsneff> It is yeah
03:17:56 <lkurusa> I'd try to negotiate MS's offer to make sure they include compiler / os / what-you-enjoy in those 8 weeks
03:18:18 <lkurusa> you have two other verbal offers which comes in handy when talking to MS
03:18:26 <JManGL> I wouldn't..
03:18:31 <lsneff> I asked the recruiter what team I'd be on and she didn't really know
03:18:54 <lsneff> Just that I'd be in the core product group
03:18:58 <lsneff> which could mean anything
03:19:05 <lkurusa> Right
03:19:26 <lkurusa> What are the other two companies if you don't me asking?
03:19:31 <lkurusa> s/me/mind me/
03:19:37 <JManGL> Whatever you get will be great experience, trying to negotiate Compiler experience as an intern/whatever is not likely to succeed. Unless I misunderstand (which I could!) these things are programs they run to give people experience? So I imagine there is already some defined structure to them?
03:20:07 <lkurusa> JManGL: if this is like Google's STEP then you could talk to the team/recruiter to guide where you spend some weeks
03:20:20 <lsneff> lkurusa: Oasis Labs and fastly
03:20:22 <JManGL> OK, in that case that's cool!
03:20:26 <lkurusa> but you're entirely right it could be a predetermined programme
03:20:29 <lkurusa> i have no idea about MS sadly
03:20:49 <lkurusa> lsneff: Out of those three, I'd go with MS
03:21:12 * lkurusa needs to go for a bit
03:21:19 <lsneff> Thanks for the help :)
03:21:33 <lkurusa> Np, good luck on os..err..careerdev
03:21:50 <lsneff> Haha, yep!
03:24:31 <lsneff> I think I'll go with ms
03:27:50 <lsneff> Then I'll go do startups next summer
03:27:53 <rakesh4545> what is the correct way to exitbootservices(). I followed the specs and it is giving invalid parameter status. i.e 8000..02
03:35:07 <lsneff> Okay, question: How should I reject a verbal-offer while still leaving it open for the future?
03:35:26 <bcos_> Ask if you can postpone?
03:36:17 <lsneff> Oh, that's a good idea. "Hey _____, I really appreciate that you want me on your team at ____, but would it be possible to postpone until next summer?"
03:37:03 <rakesh4545> most employers hate that. They want solid answer in "yes" or "no".
03:43:21 <_mjg> lsneff: you mean a job offer? is that the internship thing?
03:43:50 <_mjg> lsneff: basically you want to present yourself as happy to take it, but XYZ means you will have to wait
03:54:22 <lsneff> _mjg: what if XYZ is another internship offer?
03:54:43 <JManGL> lsneff: Hey, thank you for your offer, it looks like a fantastic opportunity. However, I've made the difficult decision to accept an offer from another company. Thank you for your time.
03:56:04 <JManGL> Don't bother with trying to postpone stuff. That is like trying to have your cake and eat it. If you can get an internship there this year, you will be able to next year.. You should be even more able to get one next year with the MS experience behind you.
04:00:28 <lsneff> Okay, thanks.
04:01:16 <lsneff> Yeah, I appreciate the advice.
04:19:25 <lkurusa> I'm with JManGL on this one
04:21:25 * mrvn is unmotivated
04:25:59 <glauxosdever> Alright. Converted my El-Torito stage-1 to nasm syntax, now to write stage-2. It will return to real mode for BIOS interrupts, then go back to protected mode. Now I'm wondering whether it should also do paging (or if I should delay it until just before the boot abstraction layer)
04:27:04 <rakesh4545> I am unable to ExitBootServices(). I followed the specs and it returns 800.002 Status
04:28:32 <glauxosdever> Code?
04:31:53 <rakesh4545> The code is pretty messy. I am looking a correct way to execute ExitBootServices();
04:33:57 <glauxosdever> http://wiki.phoenix.com/wiki/index.php/EFI_BOOT_SERVICES#ExitBootServices.28.29 <- Here is says to do GetMemoryMap() immediately before doing ExitBootServices()
04:56:01 <qwertyuiop12345> Hello
04:56:56 <mischief> rakesh4545: i suggest you give the uefi specification a good read through
04:57:12 <qwertyuiop12345> Which one is considered the "best practice"?: Building your app in host machine and then including the artifact inside your container, or building your app inside the container at image-build-time?
04:57:22 <qwertyuiop12345> Docker specifically
04:57:34 <mischief> qwertyuiop12345: this question has nothing to do with osdev.
04:57:42 <qwertyuiop12345> Didn't know where else to ask
04:57:57 <mischief> how about the docker channel
04:57:58 <mrvn> best practice is to not use docker
04:58:08 <qwertyuiop12345> Too inactive
04:58:19 <mischief> patience is a virtue.
04:59:18 <qwertyuiop12345> mrvn: What's wrong with it?
04:59:25 <mrvn> everything
05:00:17 <mischief> qwertyuiop12345: a benefit of building in container is you keep all the build process with it.
05:01:38 <mischief> keeping your build process in an image simplifies some things
05:02:09 <mrvn> mischief: that's what a chroot is for
05:02:23 <mrvn> or a build server
05:02:37 <qwertyuiop12345> How will you get Windows noobs to cooperate though?
05:02:53 <mrvn> Who says I want windows noobs?
05:02:57 <mischief> qwertyuiop12345: by using a suitable build infrastructure
05:04:31 <mrvn> qwertyuiop12345: have you even started implementing container support in your OS?
05:04:50 <qwertyuiop12345> i have already ported the docker
05:05:26 <mischief> i somehow doubt this has anything to do with osdev.
05:05:43 <mischief> hm
05:05:48 <mischief> looks like microsoft ate deis
05:18:01 <lkurusa> DOCKAAAAAAAAHHHHHHHHHH
05:22:55 <rakesh4545> mischeif: oh thanks for the suggestion
05:29:28 <mischief> mmu man, mmu man, doing the things an mmu can, does he fault? it's not important, mmu man
05:36:08 <rakesh4545> https://pastebin.com/L6qH7Hz1
05:36:15 <rakesh4545> This is my code
05:38:09 <rakesh4545> This is the output https://i.imgur.com/mGJmcdK.png
05:47:37 <mischief> somehow i dont think you need 40mb for the memory map
05:48:57 <mischief> rakesh4545: EFI_INVALID_PARAMETER
05:49:21 <mischief> you've passed an invalid parameter to ExitBootServices.
05:49:29 <mischief> i suggest you read the documentation for it
05:53:04 <mischief> looks like you could just call GetMemoryMap/ExitBootServices again in case of failure the first time.
05:57:13 <rakesh4545> I get the same error twice.
05:57:31 <rakesh4545> mischief ^
05:57:46 <mischief> using ovmf?
05:57:58 <rakesh4545> yes ovmf
05:58:17 <mischief> i'd suggest you rebuild ovmf and enable the debug flags
05:58:32 <mischief> IIRC theres some way to make it write out to the serial line.
05:58:41 <isaacwoods> if `Print` is using the console out stuff, it's possible the memmap key is changing in between
05:58:47 <isaacwoods> it's allowed to allocate afaik
05:59:01 <mischief> good call
05:59:05 <mischief> try not printing anything.
05:59:30 <mischief> (via efi runtime, anyway)
06:00:54 <mischief> yeah, the documentation even says ConOut and friends are erased
06:01:07 <mischief> so using them probably invalidates the key
06:07:46 <rakesh4545> I think that actually worked. But now as soon as BootServices Exits kemu internal error occurs. https://i.imgur.com/1Dr4P2G.png
06:08:08 <aalm> .roa
06:08:08 <glenda> 7 Keep your ears open.
06:09:30 <mischief> rakesh4545: try witout -enable-kvm?
06:09:44 <lkurusa> File a bug report please
06:09:51 <lkurusa> .theo
06:09:51 <glenda> Riiiiiiiiight. Suuuuuuuure. Keep believing that.
06:10:09 <aalm> i do
06:10:11 <aalm> .ken
06:10:11 <glenda> You can't trust code that you did not totally create yourself.
06:10:20 <mischief> word
06:10:28 <lkurusa> reflections on trusting trust
06:13:35 <rakesh4545> fixed it. Now it is working good.
06:14:35 <isaacwoods> rakesh4545: was it -enable-kvm?
06:14:44 <rakesh4545> have you seen, I made this -> https://i.imgur.com/AZzRCHQ.png
06:15:28 <isaacwoods> neat
06:15:44 <abysslurker> o/
06:16:11 <rakesh4545> No not enable-kvm ,one misplaced boot service procedure.
06:18:18 <rakesh4545> that traveller is me...
06:24:19 <mischief> ages ago i made some rust bindings for efi.
06:24:31 <mischief> tho its kinda sad and old now. :(
06:25:06 <lkurusa> Rust <3
06:27:13 <mrvn> I should make my own compiler and call it HIO, hydrated iron oxides, commonly known as rust.
06:30:40 <rakesh4545> I use edk2
06:45:59 <olsner> mrvn: but rust refers to the fungus, not the oxidized metal
07:15:00 <shynoob> hi
07:38:23 <mrvn> if you use rust can you tell it the difference between per-thread, per-core and global data?
07:43:28 <dasabhi> hey do you think contributing to nouveau drivers decreases your chances of getting a job at nvidia?
07:43:53 <dasabhi> i have been pondering this for a while
07:44:01 <dasabhi> really wanted to get into driver dev
07:44:19 <olsner> mrvn: if you have a getcpu() like function you can of course use that in rust just as well as other langauges... I forget how to access it from rust, but you can also use llvm's address space support to do gs-relative addressing without inline asm
07:45:57 <olsner> (where getcpu() is a function that returns the per-cpu structure, not just cpu number)
08:04:27 <mrvn> olsner: I'm more concerned with the locking and thread safety stuff.
08:05:16 <drakonis1> dasabhi: does it really?
08:05:33 <dasabhi> drakonis1: guess not
08:06:06 <dasabhi> have any of you guys used your os work to get hired
08:51:30 <zenix_2k2> guys one question, has there any OS which was written in Python ?
08:51:50 <mrvn> one asnwere: yes
08:52:02 <zenix_2k2> wow, can i have one example ?
08:52:08 <zenix_2k2> that sounds weird and rare
08:52:19 <mrvn> sorry, you ahve reached your one answere limit
08:53:08 <mischief> define 'os'
08:54:29 <zenix_2k2> a software which operates my machine ?
08:55:02 <mischief> there's a port of python to efi in edk2. dunno how well it works, but i think they got webservers or something dumb running.
08:56:14 <mrvn> pythons GIL is a big hindrance for OS work
08:56:19 <zenix_2k2> yea but like the kernel, what i meant was has anyone used Python to write one ?
08:56:28 <zenix_2k2> i believe it is what operates the entire system
08:57:25 <zenix_2k2> yea let's me ask this in #kernel
08:57:27 <froggey> there was Unununium, but it has almost completely vanished from the internet
08:58:31 <mischief> zenix_2k2: that's for the linux kernel.
08:58:52 <zenix_2k2> yea, it is still C i think
08:59:02 <mischief> ....
08:59:26 <zenix_2k2> the linux kernel is written in C, what did i say wrong ?
09:01:48 <mischief> the linux kernel has little to do with writing an os in python
09:05:37 <zenix_2k2> yea, i think what i meant was has someone written a kernel in Python, but i think i got it in #kernel
09:05:47 <zenix_2k2> gotta find a better way to put my sentences next time :P
09:12:14 <ox6> the python interpreter I have seen in EFI works well but I have only used it in efi shell; most on the bootblock stuff is asm/C iirc though
09:12:31 <ox6> in edk2 anyway
10:36:02 <jjuran> Unununium is Unobtanium?
11:25:30 <aalm> .roa
11:25:30 <glenda> 192 Never cheat a Klingon...unless you can get away with it.