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=24&m=4&d=6
00:36:00 <Ermine> apple mouses are not great either
00:39:00 <heat_> magic mouse!!!
00:40:00 <heat_> they trolled wireless mouse fans hard and i appreciate that
06:28:00 <kof673> > cant you replace the WM on a mac old next stuff i think let you (or you could) do a few things with the login screen at least, maybe just the graphic, do not recall. i'm sure it has mutated if not been replaced in the past ~20-25 years, just objective-c surely *in theory* allowed overriding all kinds of things (again, other langs nowadays too...)
06:29:00 <kof673> this is just to say, in theory it was all very interceptor pattern-ish at some point.....
06:31:00 <kof673> not unlike the xz thing <runs>
06:34:00 <childlikempress> the xz thing was malicious actors getting to run code on your computer + no language-level fine-grained object capabilities
06:34:00 <childlikempress> if it hadn't been ifunc, it would have been somethign else
06:36:00 <kof673> well there was a selinux way to block it but yeah re: "no language-level [...]"
06:37:00 <kof673> i just meant that is one reason maybe "mac" stuff is locked down a little :D
06:37:00 <childlikempress> at the system level, unix is a capability-safe programming language, but the granule is 'process', which is too coarse
06:37:00 <childlikempress> inter-process communication is slow and unergonomic
06:38:00 <childlikempress> so it doesn't scale down nearly far enough. you could put always put xz/whatever in its own process rather than link to liblzma, but there comes a point past which that's not workable
14:19:00 <junon> I'm reading the ARM recursive mapping section at the very end of https://wiki.osdev.org/ARM_Paging
14:19:00 <bslsk05> ​wiki.osdev.org: ARM Paging - OSDev Wiki
14:19:00 <junon> I'm getting the sense that recursive mapping on ARM isn't preferred? I also flatly do not understand what that last paragraph is saying lol.
14:19:00 <junon> Are direct maps more prevalent on ARM?
14:19:00 <heat_> direct maps are more prevalent everywhere
14:20:00 <junon> really! so the memory tradeoff isn't as important in the end, I assume
14:21:00 <heat_> the main concern is usually more about security
14:21:00 <heat_> but direct maps are really a lot more straight forward, and a lot faster
14:21:00 <junon> Right, that was my next question. If I did a DM in the lower half, and whenever a userspace program is running, those mappings are just pulled straight out, correct?
14:22:00 <junon> What are the security concerns with that?
14:22:00 <heat_> yes
14:22:00 <heat_> the solution here is
14:22:00 <heat_> >If I did a DM in the lower half
14:22:00 <heat_> dont
14:23:00 <heat_> the security concerns are more of a "everything's mapped, so if you have a read/write primitive you can write to anywhre/anything that's directly mapped"
14:23:00 <heat_> which is true
14:23:00 <junon> right, though if they're not mapped at all, then no userspace process would ever be able to access them, right?
14:24:00 <junon> I feel like TLB cache thrashing would become a problem with a lower-half direct map.
14:24:00 <junon> So is it just a matter of using e.g. supervisor-only page configs?
14:24:00 <junon> and mapping into the higher half?
14:25:00 <heat_> but you don't do lower-half direct maps
14:25:00 <heat_> "then no userspace process would ever be able to access them" except if you have a read/write primitive in the kernel
14:26:00 <junon> I'm not sure I understand, are you talking about if the kernel has a bug that allows userspace to exploit e.g. a system call or something?
14:30:00 <heat_> yes
14:31:00 <heat_> if you're able to get a read/write primitive (a way to read/write to a random place at your will), you can write to the entire memory
14:32:00 <junon> But in theory that's also possible with a recursive memory map anyway at that point, right?
15:04:00 <heat_> junon, yes but the attack surface is diminished
15:07:00 <zid> and you could randomize it if you wanted :D
15:07:00 <zid> 1/256 chance!
16:22:00 <Ermine> I guess uefi multiboot2 bootloader can't set screen to PixelBltOnly mode?
16:24:00 <zid> your uefi can boot mb2?
16:24:00 <zid> mine only boots gpt partitions
16:25:00 <zid> by looking for boot.exe
16:39:00 <heat_> Ermine, it can, it just wont be able to give you a linear fb
16:40:00 <Ermine> so os will need to use GOP's Blt
16:42:00 <heat_> you can't do that
17:48:00 <Ermine> Yay, linux 6.8 got my wifi adapter fixed
17:54:00 <siak> Ermine: Nice.
17:56:00 <heat_> if you were using debian you'd need to wait like 4 years for that fix
18:03:00 <Ermine> that's why i don't use debian
18:03:00 <gog> hi
18:04:00 <Ermine> hi gog
18:25:00 <nikolar> Hello
18:25:00 <zid> shh we're on high alert for insurgents
18:50:00 <geist> junon: also that page was for armv7, for armv8 the page tables changed, and i'm fairly certain they're not recursive mapping compatible
18:50:00 <geist> there are fundamental differences in the inner vs leaf note entries that it hink would not work
18:51:00 <geist> well, okay, i think with long format it *sort* of works, but i remember talking about it here and mapping it out and i think it will break
18:51:00 <geist> like it'll work in a simple case, if you dont use any of the optional features, but as soon as you do some of the upper page table bits start to get used for other purposes
18:51:00 <geist> and then i think it gets incompatible pretty quickly
19:29:00 <gog> osdev
19:33:00 <mjg> OH
19:41:00 <shikhin> osdev
19:48:00 <nikolapdp> OSDEV
19:48:00 <Ermine> O S D E V
19:50:00 <heat_> ohsdev
19:50:00 <mjg> i'm triggered
19:50:00 <mjg> i tried to use an os but they don't ship an image
19:51:00 <mjg> you have to compile everything yourself
19:51:00 <nikolapdp> is that serenity os
19:51:00 <mjg> ya
19:51:00 <nikolapdp> lol had the same issue
19:51:00 <nikolapdp> for some reason they don't provide weekly iso or something
20:07:00 <Ermine> openbsd 7.5 got released
20:08:00 <Ermine> mjg: COMPILE ONYX
20:19:00 * kof673 .oO( ship a bootstrap image...whereby, they must then compile things themself )
20:29:00 <heat_> the best part about compiling onyx is writing the instructions you wish you could've read
21:20:00 <Ermine> better than shitty BSPs with no adequate instructions
22:40:00 <geist> i should compile onyx on a VAX
22:45:00 <gog> onvax
23:18:00 <Ermine> how to support vax actually