Search logs:

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=5&d=11

Friday, 11 May 2018

00:00:00 --- log: started osdev/18.05.11
00:06:38 --- quit: Rodya_ (Quit: Leaving...)
00:07:53 --- join: aalm (~aalm@37-219-119-194.nat.bb.dnainternet.fi) joined #osdev
00:12:46 --- quit: aalm (Ping timeout: 268 seconds)
00:15:11 --- join: aalm (~aalm@37-219-119-194.nat.bb.dnainternet.fi) joined #osdev
00:20:41 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
00:21:13 --- quit: elevated_ (Ping timeout: 256 seconds)
00:24:51 --- join: zanneth (~zanneth@162.243.41.122) joined #osdev
00:24:51 --- quit: oaken-source (Quit: Lost terminal)
00:25:33 --- quit: elevated (Client Quit)
00:25:53 --- quit: jakogut (Quit: jakogut)
00:26:15 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
00:26:29 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
00:27:38 --- quit: bitch (Ping timeout: 276 seconds)
00:30:24 --- quit: jakogut (Client Quit)
00:30:49 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
00:31:25 --- join: bitch (hctib@gateway/shell/elitebnc/x-gbkjpuzkllxbmusk) joined #osdev
00:39:49 --- quit: magnificrab (Ping timeout: 240 seconds)
00:40:26 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
00:43:21 --- quit: zanneth (Quit: leaving)
00:43:32 --- join: zanneth (~zanneth@162.243.41.122) joined #osdev
00:43:41 --- join: t3hn3rd (~Logic_Bom@cpc91224-cmbg18-2-0-cust219.5-4.cable.virginm.net) joined #osdev
00:44:57 <t3hn3rd> Hey all, anyone around able to give me a bit of help/advice with network stack issues? Feels like I've been banging my head against a wall for the last god-knows how many hours, and I'm starting to go a little insane.
00:45:34 <klange> How many goats have you sacrificed?
00:45:34 <Mutabah> Tomato duck elephant shoelace
00:45:52 <t3hn3rd> I knew it, it's too late for me.
00:46:01 <t3hn3rd> ;P
00:46:26 <t3hn3rd> I've sacrificed 0 goats thus far, but it's on my to-do list.
00:47:05 <_mjg_> 1. ignore the common wisdom
00:47:10 <_mjg_> 2. wonder why it does not work
00:47:13 <_mjg_> 3. ???
00:47:15 <_mjg_> 4. profit
00:47:23 <Mutabah> Ok, all jokes aside... What's the problem?
00:47:29 <t3hn3rd> To-do list goes something like: Get ARP response from F#*!&! router -> sacrificial goats.
00:47:56 <Mutabah> Are you using qemu? If so, enable dumping on that vlan
00:48:02 <Mutabah> (it can write all packets to a file)
00:48:14 <klange> I saw a packet dump from t3hn3rd already, so I think that's covered.
00:48:15 <Mutabah> Then you can tell what's being sent (and if it's being sent at all)
00:48:32 <Mutabah> Check that you're sending to the right MAC/IP too
00:48:42 <Mutabah> I think the qemu router is on .2 not .1
00:48:49 <Mutabah> s/qemu/user net/
00:49:21 <t3hn3rd> So, have been implementing ARP, but am getting no responses from the router, examining the packets in Wireshark shows no issues, infact I'm going further than other devices and actually implementing the CRC for eth frames correctly, but the router simply refuses to respond to my ARP requests, I have tested the implementation by using another computer and attempting to ping my OS, obviously the ping bounced as ICMP
00:49:21 <t3hn3rd> isn't implemented on the OS, but my OS replied to its ARP request and the testing computer had my IP/MAC in its ARP Cache
00:49:37 <klange> yup https://i.imgur.com/y8FbLDz.png
00:49:59 <Mutabah> yeah, I got bit by that when testing my network stack recently :)
00:50:13 <Mutabah> ... I should go see if acess still boots
00:50:31 <klange> I was pulling it out of DHCP before I even started working on ARP.
00:50:35 <t3hn3rd> My network is /24, so broadcast is 192.168.1.0, Gateway is 192.168.1.1, my OS is 192.168.1.243, testing computer (Windoze) is 192.168.1.217
00:50:53 <Mutabah> What sort of test network is it?
00:51:31 <t3hn3rd> My home network, Asus router with AsusWRT, OS is running in virtualbox using a E1000 driver bridged to my host adapter.
00:51:42 <t3hn3rd> Promisc is enabled on both the VMs and the NIC
00:51:49 <t3hn3rd> Packets are received and sent correctly
00:52:18 <Mutabah> And you're trying to ARP .1 and not getting a reply?
00:52:22 <Mutabah> Does .1 see the ARP request?
00:52:22 <t3hn3rd> Just seem to be ignored by the router and never responded to by devices, the devices happily keep my ARP replies, but just don't respond to request.
00:52:50 <t3hn3rd> I'd assume that .1 has to have seen it, as .217 is able to receive it
00:53:07 <Mutabah> I assume .217 is the VM host, so it may have an unfair advantage
00:53:12 <t3hn3rd> Nope
00:53:22 <t3hn3rd> Seperate computer connected to the gateway over ETH
00:53:25 <Mutabah> Can you ARP .217
00:53:31 <t3hn3rd> No reply
00:54:05 <Mutabah> So .217 gets the ARP request, but does not respond to it?
00:54:13 <t3hn3rd> Yeah
00:54:24 <t3hn3rd> It even stores my MAC/IP in its cache
00:54:29 <t3hn3rd> Just decided not to reply
00:54:35 <t3hn3rd> decides*
00:54:45 <Mutabah> The packet is correctly formatted? Correct MAC/IP in both the ethernet and ARP headers?
00:55:52 <t3hn3rd> I believe so, will post screenies in a sec
00:58:08 <t3hn3rd> So, crude network topology: https://i.gyazo.com/d8006bb8d06d649073e8c3d2f742ac3e.png
00:58:34 <t3hn3rd> A working ARP request from another device on the network: https://i.gyazo.com/08af75ddcf1c1815c58fb91c74577dd6.png
00:58:45 <t3hn3rd> My ARP request: https://i.gyazo.com/903cffc14656388df0497a49c2306501.png
00:59:29 <t3hn3rd> Most other devices don't even seem to follow the 64byte rule for ETH frames, they just pad to 60 and include the FCS in the padding
01:00:16 <t3hn3rd> Was reading, and Target MAC can apparently be either all zero's or all F's for a request
01:00:24 <t3hn3rd> have tried both, no difference.
01:02:19 <SGautam> Hm, when are we going to have advertising on IRC
01:02:49 <SGautam> When is ChanServ going to tell me the secret to make 1000 US dollars a month
01:02:50 <SGautam> :P
01:03:18 <SGautam> I mean, seriously speaking it could definitely be possible.
01:03:28 <Mutabah> t3hn3rd: Maaaybe don't pad your frame?
01:03:30 <klange> This channel is brought to you by Squarespace™.
01:03:47 <Mutabah> t3hn3rd: The minimum size is iirc handled by the netowrk card
01:04:00 <klange> Squarespace™ powers millions of websites across hundreds of industries for people just like you.
01:04:01 <t3hn3rd> Mutabah - was doing that at first, didn't pad and didn't add FCS, same deal
01:04:14 <SGautam> klange: oh no
01:04:19 --- quit: magnificrab (Ping timeout: 240 seconds)
01:04:27 <SGautam> the infestation has already started
01:04:29 <Mutabah> Try again and do a flip-compare between the two frames, see if you can find something that's notably different
01:04:33 <t3hn3rd> Network card didn't seem to handle it, ended up with 43bytes on the wire
01:04:43 <SGautam> the ultimate kicker though would be
01:04:46 <SGautam> paid channels
01:04:49 <Mutabah> t3hn3rd: What wireshark sees isn't exactly on the wire
01:04:57 --- quit: geordi (Remote host closed the connection)
01:05:53 <t3hn3rd> So I should remove the padding and FCS?
01:06:04 <Mutabah> Try it like that
01:06:09 <Mutabah> or try with just the FCs
01:06:27 --- join: k4m1 (~k4m1@206.189.46.228) joined #osdev
01:06:38 <t3hn3rd> Will give that a go!
01:06:42 <Mutabah> Idea is to make your packet look as similar as possible to a known-working one
01:06:56 <SGautam> this is so offtopic but is anyone familiar with FlightGear
01:07:02 <Mutabah> ... yes
01:07:21 <t3hn3rd> I did just that, I padded to 60bytes with the FCS contained within the last 4 bytes, just as the Roku device does, but still no joy
01:07:30 <t3hn3rd> Will try removing the padding now
01:07:51 <SGautam> Mutabah: I've only tried FS2004 and X-Plane 10 till now, but since I'm on Linux, I might as well have go at it.
01:08:00 <SGautam> Although I'm currently on a mobile processor and GPU
01:08:03 <Mutabah> t3hn3rd: If it's identical and you still can't ARP anything, there's something REALLY strange happening
01:08:21 <Mutabah> SGautam: It's not bad considering its price :) Wonderfully configurable
01:08:44 <Mutabah> But quirky in places (I've "crashed" the 172 far too many times from unstable taxiing)
01:08:49 <t3hn3rd> Mutabah: before I went to bed last night, I tried simply padding all zero's to 60 bytes, which is what my Ubuntu environment does, and that also failed.
01:09:29 <SGautam> Mutabah: I'm guessing it comes with most of the popular planes? I'm mostly hacking around with 7XX or some of the passenger Airbuses (320/330/380)
01:09:31 <Mutabah> Try different target IPs? Try changing the VM's MAC?
01:09:49 <Mutabah> SGautam: Comes with a 777 and 172 iirc (plus a few others)
01:09:54 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
01:09:58 <SGautam> I've never liked the C172 :/
01:10:47 <SGautam> Mutabah: Okay thanks I'll check it out
01:13:06 --- quit: k4m1 (Quit: brb)
01:13:50 <Mutabah> Reminds me, I should go for a lap around YPJT tonight
01:14:44 --- join: geordi (~geordi@ns510081.ip-192-99-4.net) joined #osdev
01:14:46 --- quit: geordi (Remote host closed the connection)
01:16:07 --- join: geordi (~geordi@ns510081.ip-192-99-4.net) joined #osdev
01:16:23 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
01:19:18 --- quit: SGautam (Ping timeout: 246 seconds)
01:20:59 <t3hn3rd> Just tried - no luck, tried removing padding, removing padding + FCS, removing FCS and just having padding, padding to 60-bytes and including FCS in last 4 bytes of padding (like other devices are doing) no luck :/
01:21:21 <Mutabah> So, your packets look nigh-identical in wireshark?
01:21:37 <Mutabah> Tried different target addresses? Tried a different local address?
01:21:45 --- quit: ACE_Recliner (Ping timeout: 246 seconds)
01:21:54 <t3hn3rd> weirdly, I've just had a look at a request that got a response from a device on the network, and the FCS included in bytes 57, 58, 59 & 60 don't even match the correctly calculated FCS...
01:22:07 <t3hn3rd> Yeah, basically identical from what I can tell
01:22:32 <t3hn3rd> Yeah, tried different targets, and tried a few different local addresses, along with changing the VMs MAC.
01:23:15 <t3hn3rd> Absolutely bizarre, annoyingly, I used to work in Network forensics, so this should be my bread & butter.
01:23:55 --- quit: nur (Quit: Leaving)
01:24:17 <Mutabah> Well, there's definitely something different
01:24:18 --- quit: magnificrab (Ping timeout: 268 seconds)
01:24:48 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
01:25:23 --- quit: Pseudonym73 (Remote host closed the connection)
01:25:29 --- join: nur (~hussein@slb-97-111.tm.net.my) joined #osdev
01:25:47 <t3hn3rd> At first I thought it might be something with the driver on my OS, given it seems to stop receiving packets after a while (think it might be a power-state, as it seems to happen when Virtualbox loses focus), but given that the packet is received on a completely separate device but no response is ever generated, I don't think it's a driver issue
01:28:05 <Mutabah> Hmm... waiiit
01:28:15 <Mutabah> Try running the capture on the VM host
01:29:12 <t3hn3rd> https://i.gyazo.com/b2394a3236a62bbdad000a5e82670c58.png
01:29:17 <t3hn3rd> have been
01:29:26 <Mutabah> Oh, these whave been from the host?
01:29:27 <t3hn3rd> capture is running on VM Host and .217
01:30:02 <Mutabah> can you arp for the VM and have the host see it and the reply?
01:30:25 <Mutabah> better, can you ping the vm and see the pings hit it in the host's capture?
01:30:44 <t3hn3rd> i.e. have the host make an ARP request to the VM and see if it gets a response?
01:31:11 <Mutabah> Have the other machine ping the VM (not ARP) and see if the host sees the ping arrive
01:32:59 <t3hn3rd> Host sees the pings, but obviously not replies as ICMP isn't implemented in my network stack yety
01:33:01 <t3hn3rd> yet*
01:33:18 <klange> i like your TUI windowing system ;)
01:33:23 <t3hn3rd> host also sees an ARP request for my OSs MAC, and a reply from my OS
01:33:49 <Mutabah> Ok, so there goes that theory...
01:34:13 <t3hn3rd> klange: Aha thanks :P Theme sucks ass, but has been fun to make
01:34:49 <t3hn3rd> Mutabah: I'm just confused, my router doesn't enforce DHCP, I have statically configured devices on the network, it's bizarre.
01:34:52 --- quit: magnificrab (Remote host closed the connection)
01:35:08 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
01:35:30 <t3hn3rd> Is there a certain way I'm supposed to announce myself? Once ifconfig is run, I'm sending a gratuitous ARP and then a request for 192.168.1.1
01:35:43 <Mutabah> I'm also confused... there must be something you've missed
01:35:48 --- join: SGautam (~GautamS@unaffiliated/gautams) joined #osdev
01:35:58 <Mutabah> Try arp-ing the vm host?
01:36:06 <Mutabah> Cut the router/switch out of the equation
01:36:21 <t3hn3rd> There absolutely must be something I've missed, agreed.
01:36:26 <t3hn3rd> Will try that now, sec
01:37:47 --- join: virtx (05391581@gateway/web/freenode/ip.5.57.21.129) joined #osdev
01:39:09 <virtx> can someone please explain to me how this "pop SS" vulnerability works? when SS register is loaded the ESP/RSP should be always fixed with the stack of new segment?
01:39:12 <virtx> also in long mode?
01:39:41 <virtx> I am asking because in long mode segmentation is not used, so what pop/mov SS does?
01:39:54 --- quit: glenda (Ping timeout: 265 seconds)
01:40:07 <geist> you can still fiddle with the registers, they just generally dont do anything
01:40:11 <t3hn3rd> No joy, no reply from the VM host: https://i.gyazo.com/e07dc6d1f301ffd0d7210cf8f02646e7.png
01:40:19 <Mutabah> virtx: When SS is modified, all interrupts are deferred until after the next instruction
01:41:04 <virtx> so how the user/kernel stack can be abused in that scenario?
01:41:14 <Mutabah> If the user has `TF` set, and the next instruction is a kernel entry (e.g. `int` or `syscall`), the trace exception is raised with RIP pointing into kernel-space
01:41:25 --- join: zeus (~zeus@197.239.5.31) joined #osdev
01:41:36 <Mutabah> (oh, and the CPU actually running in kernel mode)
01:41:39 --- quit: zeus (Client Quit)
01:41:46 <virtx> if I have mov ss, ax ; syscall (or int3) the syscall will switch to kernel mode stack, right?
01:41:52 <Mutabah> nope
01:41:58 <Mutabah> syscall doesn't do that, sysenter does iirc
01:42:07 <virtx> oh, right, sysenter, sorry
01:42:12 <Mutabah> (It's one of the annoying things about syscall actaully)
01:42:18 <geist> but i think in this case you follow up the mov ss with an int instruction
01:42:37 <Mutabah> Yeah... i didn't look into the details really
01:42:55 <geist> https://www.theregister.co.uk/2018/05/09/intel_amd_kernel_privilege_escalation_flaws/ seems to have a decent summary
01:42:56 <bslsk05> ​www.theregister.co.uk: Every major OS maker misread Intel's docs. Now their kernels can be hijacked or crashed • The Register
01:43:18 <virtx> so I got that the issue is that mov ss ; int3 generate a #BP and it is handled after the next instruction, but why this is affect the kernel/user stack?
01:43:56 <virtx> the pdf doc about this vuln is very bad written, or they assume a very skilled readere
01:44:21 <geist> i think it's all about swapgs at some point
01:44:44 <geist> since you end up double entering the kernel and doing a #DB or something
01:45:00 <geist> it's too late to fully grok it here, but it's a fairly tricky sploit
01:45:00 --- quit: EvanCarroll (Remote host closed the connection)
01:45:13 <geist> what i still haven't gotten clear is if AMD cpus act precisely the same way
01:45:47 <bcos_> AMD CPUs should act the same - it's well defined and well documented behavior that probably dates back to 8086
01:46:36 <bcos_> (except for the "always stupid" design of the SYSCALL addition)
01:47:13 <geist> anyway, this case is basically an interesting exacmple of a weird edge case in the arch that everyone collectively misunderstood
01:47:49 <geist> and there's a fair amount of 'what does linux/bsd/etc do?' when it comes to tricky things like this
01:47:59 --- quit: elevated (Quit: bye)
01:49:19 --- join: aaron (~BrainFog@cpc89010-gill18-2-0-cust1263.20-1.cable.virginm.net) joined #osdev
01:49:38 <geist> there's a mention in the article that i think implies the damage is worse on AMD because of the sycall instruction
01:49:42 --- nick: aaron -> Guest46701
01:49:51 --- join: glenda (~glenda@mischief-1-pt.tunnel.tserv29.fmt1.ipv6.he.net) joined #osdev
01:49:52 <geist> though as far as i know everyone just uses syscall for 64bit kernels (instead of 64bit sysenter)
01:50:08 <geist> though on 32bit kernels i think most designs use sysenter
01:50:19 --- quit: hmmmmm (Remote host closed the connection)
01:50:34 --- quit: Guest61153 (Read error: Connection reset by peer)
01:52:29 --- quit: zesterer (Ping timeout: 250 seconds)
01:52:52 <Brnocrist> linux had the IST patch from 3 years and never applied..
01:53:18 <Mutabah> Oooh....
01:53:22 <Mutabah> it just hit me, yeah, ow
01:53:42 <Mutabah> with syscall the user controls the kernel stack
01:54:17 <Mutabah> with some tight timing, you could go and corrupt the iret ...
01:54:52 <Mutabah> (trigger exploit, be watching the memory on another core and when the interrupt frame appears, replace it with your own
01:58:55 <virtx> how kernel stack is controlled from userspace with syscall?
01:59:51 <clever> it would probably murder performance, but what about just not having the userland mapped when in kernel mode?, and only map the regions on-demand as needed
02:00:06 <clever> then the kernel can never accidentally read user controlled ram
02:00:17 <virtx> there is SMAP for it
02:00:39 <Mutabah> clever: That's what was done for meltdown iirc
02:00:44 <clever> or just sprinkle the kernel with assertions that a given bit in the stack pointer must be a given value
02:00:56 <clever> Mutabah: my understanding is that meltdown protections did the reverse, kernel is never mapped in user mode
02:01:06 <clever> so you cant peek at kernel space
02:01:08 <virtx> KPTI is the opposite, it prevents to map kernel mem in userspace
02:01:13 <Mutabah> virtx: The `syscall` instruction enters kernel mode without setting the stack pointer
02:01:16 <Mutabah> clever: Ah, yes.
02:01:42 <virtx> Mutabah: it is done in syscall handler, right?
02:01:45 <clever> but if you apply the same thing in reverse, then the stack pointer being wrong just causes a fault in kernel mode
02:01:48 <Mutabah> Actually, that mitigation can't work... because there's no way to unmap
02:02:13 <bcos_> number_of_problems_caused_because_syscall_doesn't_switch_stacks++; // Current value is probably at least 10 by now
02:02:15 <Mutabah> virtx: Well, yeah, first thing the handler does is set the stack pointer
02:03:42 <virtx> my understand about this pop ss vuln is, mov ss, ax cause a #DB, DB is handled after syscall/int following the mov, so when syscall/int is handled swapgs happend in the handler so now the stack is switched to kernel mode. But when #DB is handled after syscall/int the stack is still in kernel mode and another swapgs is runned inside #DB handler, so it will switch to user mode stack ?
02:04:30 <Mutabah> virtx: 1. Set up a debug breakpoint such that a specially-crafted `pop ss` triggers it
02:04:45 <Mutabah> virtx: When that is run, the breakpoint 'fires' but doesn't actually run the interrupt yet
02:05:03 <Mutabah> virtx: Next instruction is something that enters kernel-mode (e.g. syscall or int)
02:05:24 <Mutabah> virtx: Kernel mode is entered, and the cpu is "sitting" at the top of the entry handler
02:05:56 <Mutabah> virtx: The deferred breakpoint from step 2 actually fires (entering the handler for that, but with the saved CPU state pointing to the kernel area)
02:06:36 <Mutabah> Actually... Not sure if the saved state points there? But that doesn't matter much because...
02:06:54 <virtx> so yes, BP handler expect usermode CPU state, but if it happens after syscall/int we are in kernel mode state?
02:07:02 <Mutabah> `syscall` doesn't set a stack, so at this point RSP=<some_user_value> but the debug breakpoint handler expects it to be <some_kernel>value>
02:07:23 <bcos_> You're already screwed at that stage - e.g. user-space sets RSP to the address of a kernel data structure, then does "mov ss" then "syscall"
02:07:36 <virtx> uh?
02:07:54 <bcos_> ..then CPU's #DB pushes stuff onto the stack, overwritting the kernel's data structure
02:08:07 <Mutabah> virtx: At the first instrction of the `syscall` handler (the instruction syscall), RSP is still whatever the user had set it to
02:08:12 <virtx> but BP handler will be executed *after* syscall handler, so after syscall returns to user mode?
02:08:20 <Mutabah> No
02:08:22 <Mutabah> Not when it returns
02:08:31 <virtx> and when?
02:08:37 <Mutabah> it runs at the next instruction
02:08:44 <Mutabah> i.e. before the first instruction of the interrupt/syscall handler
02:09:01 <virtx> if next instruction is syscall, the syscall handler is executed before #BP?
02:09:31 <bcos_> Only 3 defenses against this: kernel can refuse to allow user-space to setup/enable debugging; kernel can refuse to support SYSCALL; and kernel can use IST for #DB. I'm fairly sure Linux does do the latter
02:09:38 <virtx> if BP is executed before the mov ss instruction, where is the issue?
02:09:56 <virtx> I think the issue is that the BP is executed after mov ss following instruction
02:10:11 <virtx> so if the next insn is syscall, BP is executed after syscall
02:10:15 <Mutabah> yep.
02:10:23 <virtx> so whey syscall returns in userspace?
02:10:25 <Mutabah> After the `syscall` instruction _retires_
02:10:40 <virtx> ah, so after instruction, not after syscall handler
02:10:41 <Mutabah> Not just before the instruction after `syscall` in the program woudl run
02:10:49 --- quit: JusticeEX (Ping timeout: 240 seconds)
02:11:10 --- quit: SGautam (Read error: Connection reset by peer)
02:11:59 <virtx> so: 1) set BP on eax address value, mov SS, eax ; syscall -> BP is triggered on mov SS, eax. syscall instruction is executed (not the syscall handler) and then BP handler runs?
02:12:20 <bcos_> Yes
02:12:28 <Mutabah> pretty much
02:12:35 <virtx> but syscall doesn't change the stack value, so what is the issue there?
02:12:40 <Mutabah> (it has to be `pop`)
02:12:49 <virtx> when BP handler is executed the RSP is still in user space, right?
02:12:50 <Mutabah> The issue is _because_ it doesn't change SP
02:12:54 <Mutabah> yes
02:13:02 --- quit: Arcaelyx_ (Quit: Textual IRC Client: www.textualapp.com)
02:13:13 <virtx> but it should be the same also if the next insn is not syscall/int, right?
02:13:20 <Mutabah> But since the CPU is in kernel-mode, the handler doesn't load a new stack pointer
02:13:34 <virtx> lets say something like: mov SS, eax ; inc eax
02:13:45 <virtx> the issue is also there?
02:13:45 <bcos_> ^ "mov ss,[eax]"
02:13:48 <Mutabah> When an interrupt happens in user-land, (or any higher ring number) - the CPU loads a new stack before pushing state and running the handler
02:13:50 <virtx> yes
02:14:28 <Mutabah> But if it happens in kernel-land, it doesn't load a new stack (because it could already be on the stack it'd otherwise load)
02:14:48 <virtx> in this case it happens in usermode, because mov ss is in user mode code
02:15:11 <Mutabah> except that when it actually happens, the CPU is in kernel mode
02:15:29 <virtx> what do you mean?
02:15:40 <Mutabah> Think of it like this
02:16:09 <Mutabah> when the breakpoint fires, part of the cpu sets a flag saying "next time you can, run this interrupt handler"
02:16:20 --- quit: magnificrab (Remote host closed the connection)
02:16:36 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
02:16:38 <Mutabah> It can't check that after the `pop ss`, so it checks it after the next instruction is done
02:17:07 <Mutabah> When it checks it, it starts the interrupt process - (optionally switch stacks, save original state, jump to handler)
02:18:35 <virtx> ok
02:19:24 --- quit: Goplat (Remote host closed the connection)
02:19:34 <virtx> so immage it happens with not syscall/int but another isns, the BP handler is in the same state, so it is still in user space state, right?
02:20:51 <virtx> "mov ss, [eax] ; xor eax, eax" what happens here? BP is triggered on mov, but executed after xor, right?
02:21:56 <t3hn3rd> So I'm now just ingesting ARP packets whether they're meant for me or not, not ideal or correct, but only way to populate the ARP cache at the moment.
02:25:04 <bcos_> Hmm - SS loads ("pop ss", "mov ss") don't inhibit exceptions; so if you can guarantee that they will cause a #GPF (which is fine because user-space shouldn't be loading SS in the first place) there's no problem; and (for SS but not other segment registers) this is actually possible (because you can't load NULL into SS, and can ensure there's no descriptor that can be loaded)
02:25:07 <virtx> so what I understand is that mov SS must be followed with mov SP, kernel_sp always? :)
02:25:57 <bcos_> virtx: If you're doing that, you could (and probably should) be using LSS instruction instead.
02:26:36 <virtx> but it should heppen when segmentation is used, not in long mode
02:26:50 <bcos_> Long mode uses segmentation
02:27:02 <bcos_> ..it just doesn't use the "base and limit" parts of most segment registers
02:27:52 <virtx> there is just one segment
02:27:57 <bcos_> ?
02:28:16 <virtx> I mean the base is always the same
02:28:47 <bcos_> Yes - doesn't use the "base and limit" parts of most segment registers (except for FS and GS, and for "32-bit or 16-bit sub-mode of long mode")
02:28:54 <Kazinsal> It's fascinating the things people do with segmentation on modern IA-32 (well, as modern as you can get on a 32-bit x86 chip)
02:29:36 --- join: light2yellow (~l2y@185.220.70.169) joined #osdev
02:30:58 <virtx> ok, thanks
02:31:15 <virtx> so back to the question: "mov ss, [eax] ; xor eax, eax" what happens here? BP is triggered on mov, but executed after xor, right?
02:31:46 --- join: zeus (~zeus@197.239.5.31) joined #osdev
02:32:09 --- nick: zeus -> Guest87943
02:32:40 <bcos_> Yes
02:33:02 <bcos_> ..but in that case it's "mostly fine sort of" because the CPU is still running at CPL=3
02:33:44 <virtx> ok
02:34:47 <virtx> so if the instruction after mov is syscall, ESP is still user space stack, but CPL is 0 and #DB handler is running in CPL=0? (with xor it runs in CPL=3?)
02:34:55 <bcos_> ..but for "mov ss, [eax] ; int3" or "mov ss, [eax] ; ud2" or "mov ss, [eax] ; syscall" or .... the CPU switches to CPL=0 and then does the BP, so the BP happens at CPL=0
02:35:31 <virtx> ok, but #DB doesn't switch in CPL=0 to be handled?
02:35:44 <bcos_> ..but people might not have thought about "ud2" (or division by zero or any/all of the other exceptions)
02:35:47 <virtx> in normal case, I mean
02:36:42 <bcos_> Sure, normally #DB at CPL=3 causes the CPU to switch to kernel stacks start, save "return to CPL=3" information on the kernel stack, and start the exception handler
02:37:26 <bcos_> ..but #DB at CPL=0 doesn't cause the CPU to switch to kernel stack, then saves "return to CPL=0" information on the kernel stack
02:38:21 <virtx> so when syscall/int/etc. are really handled after #BP they are already in CPL=0 because of "return to CPL=0" of DB?
02:39:06 --- join: mdunn (~Thunderbi@host109-146-239-189.range109-146.btcentralplus.com) joined #osdev
02:39:41 <bcos_> Assuming that the #DB didn't cause the kernel to crash because the kernel was expecting "return to CPL=3" information on its stack; then yes
02:40:15 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
02:40:24 <bcos_> ..but its more complicated than that, because there's other complications too (GS being set to user-space and not being set to kernel space)
02:40:56 --- quit: magnificrab (Remote host closed the connection)
02:42:08 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
02:44:27 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
02:45:05 --- join: Kimundi__ (~Kimundi@i577A9653.versanet.de) joined #osdev
02:45:09 <virtx> yes, so swapgs will swap from kernel to user mode, because DB is already in CPL=0
02:45:29 --- quit: vaibhav (Quit: Leaving)
02:45:58 --- join: NaNkeen (~nankeen@115.164.80.206) joined #osdev
02:46:23 --- join: SGautam (~GautamS@unaffiliated/gautams) joined #osdev
02:46:59 <bcos_> virtx: More like, if DB interrupts CPL=0 it assumes that swapgs was already done (by whatever switched to CPL=0) and therefore doesn't do it
02:47:33 <bcos_> ..because normally when DB interrupts CPL=0 and swapgs was already done, doing swapgs a second time would ruin everything
02:47:45 <virtx> but it is not true I guess, because syscall changed just CPL and didn't swapgs yet
02:48:24 <bcos_> Yes, syscall is a nasty mess (and swapgs isn't much better - there's a new "loadgs" that doesn't swap which is a lot safer)
02:49:13 <virtx> never hear about loadgs, it is "new"?
02:50:26 <bcos_> Ah - sorry - they called it "wrgsbase"
02:50:37 <bcos_> ..and yes, it's relatively new
02:51:26 <bcos_> https://www.felixcloutier.com/x86/WRFSBASE:WRGSBASE.html
02:51:27 <bslsk05> ​www.felixcloutier.com: File Not Found
02:51:38 <virtx> thanks
02:51:50 <virtx> so now this mov/pop ss makes more sense :)
02:52:10 <bcos_> Unfortunately, "relatively new" means that it's not supported on all CPUs (that support long mode)
02:58:23 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
03:03:31 --- quit: Guest87943 (Quit: WeeChat 2.1)
03:03:55 --- join: zeus1 (~zeus@197.239.5.31) joined #osdev
03:05:49 --- quit: mdunn (Ping timeout: 256 seconds)
03:06:53 --- join: ljc (~ljc@unaffiliated/ljc) joined #osdev
03:16:01 --- quit: magnificrab (Ping timeout: 256 seconds)
03:16:15 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
03:21:19 --- quit: NaNkeen (Ping timeout: 240 seconds)
03:23:18 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
03:25:33 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-sihdaqgnvohksnez) joined #osdev
03:26:13 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
03:35:12 --- quit: ALowther (Remote host closed the connection)
03:39:42 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
03:40:43 --- quit: MaryJaneInChain (Remote host closed the connection)
03:42:33 --- quit: oldtopman (Ping timeout: 276 seconds)
03:50:29 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
03:53:12 --- join: root1 (~root@36.102.208.117) joined #osdev
03:55:41 --- quit: KioppoiK (Ping timeout: 256 seconds)
03:57:08 <XgF> bcos_: wrgsbase/wrfsbase don't help you here
03:57:32 <XgF> bcos_: they're there to allow user mode to change the GS/FS base, they don't provide any replacement for SWAPGS
03:58:13 --- quit: kasumi-owari (Ping timeout: 240 seconds)
03:58:42 <XgF> The key thing is you need SWAPGS because the syscall handler starts with absolutely no pointers to its kernel mode context, so the first thing it needs to do is to SWAPGS in order that it can load stuff like kernel RSP out of GS
03:59:49 --- join: kasumi-owari (~kasumi-ow@ftth-213-233-237-007.solcon.nl) joined #osdev
04:02:09 <lachlan_s> Is it convention to disable interrupts when in the kernel context?
04:03:52 <XgF> depends upon your kernel
04:04:48 <XgF> Most monolithic kernels don't becasue you can spend lots of time in kernel space. many microkernels od because their time-in-kernel is short
04:05:19 --- quit: SGautam (Ping timeout: 240 seconds)
04:05:35 <lachlan_s> Thanks
04:05:50 <lachlan_s> Anyone know if fuchsia can be preempted in kernel mode?
04:09:22 <izabera> https://i.imgur.com/BrJpIHx.png
04:09:36 --- quit: nortega (Remote host closed the connection)
04:09:58 <izabera> i'm in a very professional work environment
04:10:08 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
04:10:10 <lachlan_s> +1
04:15:38 <lachlan_s> I actually really like the movie that's from
04:15:42 <lachlan_s> Very iconic
04:18:00 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
04:18:09 --- join: SGautam (~GautamS@unaffiliated/gautams) joined #osdev
04:18:45 --- quit: elevated (Quit: bye)
04:21:27 --- quit: pie_ (Ping timeout: 240 seconds)
04:23:16 --- quit: light2yellow (Quit: brb)
04:25:15 <doug16k> izabera, where's the loop? hlt can wake up
04:25:24 --- join: light2yellow (~l2y@185.220.70.134) joined #osdev
04:25:45 <izabera> it's userspace code
04:25:52 <izabera> $dayjob things
04:26:19 --- quit: root1 (Ping timeout: 240 seconds)
04:30:05 <Vercas> izabera: Is that just meant to kill the process because of a #GP?
04:30:08 <doug16k> lachlan_s, there isn't a good reason to disable interrupts in kernel mode. a better question is whether a particular kernel has interrupts enabled in interrupt handlers - whether an IRQ handler can be interrupted by a higher priority interrupt handler
04:33:31 <virtx> also with nmi?
04:33:36 <doug16k> for example: on x86, the priority of an interrupt is determined by the vector. a lower numbered vector is higher priority than a higher numbered vector. an IRQ at vector 0x20 can never be preempted by another IRQ, and any IRQ is higher priority than vector 0xFF
04:34:47 <doug16k> virtx, NMI is higher priority than every IRQ. NMI is vector 2
04:35:43 <doug16k> NMI also ignores IF, so it will preempt regardless. only being in an NMI handler masks NMI, until the next iret(q)
04:35:44 <virtx> is there a priority among them? I mean if there is a nmi during a nmi handling?
04:36:08 <izabera> Vercas: yes
04:36:55 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
04:36:59 <doug16k> NMI is masked until the next iret(q) so NMI will not be preempted by another NMI
04:37:46 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
04:38:12 <virtx> right
04:39:30 <Vercas> izabera: What's wrong with just calling `abort`? Do you want memory dumps 'n stuff?
04:40:13 <izabera> it's not linked against libc
04:41:06 --- join: qeos (~qeos@ppp91-79-242-242.pppoe.mtu-net.ru) joined #osdev
04:41:46 <Vercas> Ah.
04:41:52 <Vercas> Fair 'nuff.
04:43:13 <bcos_> Erm. There's always the possibility of SMI interrupting an NMI handler, the SMI doing "IRET" (unblocking NMIs) before returning, and then a second NMI nesting in the first
04:44:01 <Vercas> bcos_: But don't SMI interrupts use a different instructions to return..?
04:44:47 <bcos_> SMM (potentially) executes billions of instructions (potentially including IRET), then uses "RSM" to return
04:45:27 --- quit: zeus1 (Ping timeout: 248 seconds)
04:45:51 --- join: glauxosdever (~alex@ppp-94-66-36-41.home.otenet.gr) joined #osdev
04:46:10 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
04:50:51 --- quit: ALowther (Ping timeout: 256 seconds)
04:51:39 <Vercas> bcos_: Found two different instances of people stating that iret doesn't enable NMIs while in SMM.
04:52:59 <bcos_> Vercas: And how many saying the opposite?
04:53:21 <bcos_> There's a warning in Intel's manual about it. Maybe Intel are wrong..
04:53:30 --- join: root1 (~root@36.102.208.117) joined #osdev
04:53:32 <Vercas> The opposite - An ancient version of the Pentium manual, which is what one of those people tested against.
04:53:49 <Vercas> And there's a reference in LWN to this possibility, but no proof for or against it.
04:54:25 <Vercas> 1. http://www.rcollins.org/ddj/Mar97/Mar97.html
04:54:26 <bslsk05> ​www.rcollins.org: The Secrets of System Management Mode
04:54:42 <Vercas> IRETD, IRET Chosen because Intel says they unmask NMI & INIT. Observed behavior contradicts Intel documentation (behavior mentioned in erratum 14 of P54C).
04:55:46 <lachlan_s> doug16k: I suppose as long as you don't preempt in a spinlock
04:56:05 <Vercas> 2. https://software.intel.com/en-us/forums/watercooler-catchall/topic/305672
04:56:05 <bslsk05> ​software.intel.com: SMI nested inside a NMI handler
04:56:47 --- join: t3h_n3rd (~Logic_Bom@cpc91224-cmbg18-2-0-cust219.5-4.cable.virginm.net) joined #osdev
04:57:19 --- quit: immibis (Ping timeout: 240 seconds)
04:57:22 <bcos_> Heh
04:57:35 <virtx> how many complications...
04:57:43 <virtx> ARM has the same thing?
04:57:54 <bcos_> Vercas: That second one (Intel's forums) is a like a form letter cut&pasted by someone that didn't even think about the question
04:58:16 --- quit: t3hn3rd (Ping timeout: 260 seconds)
04:58:49 <Vercas> Well, it explains the steps taken and says they didn't work. :P
04:59:15 <Vercas> And from the first source, here's the bit where the author states exactly what you're looking for: Normally the processor would ignore NMI or INIT while in SMM, except after an IRET instruction. This is exactly what I had done, but it didn’t work.
04:59:25 <bcos_> Sure, the person asking the question says "I don't want to IRET in SMM" and the person responding says "I didn't bother thinking about what happens if you IRET while in SMM"
04:59:59 <bcos_> Read Intel's manual, section "34.8 NMI HANDLING WHILE IN SMM"
05:00:41 <bcos_> ^ this even has things like "if the SMM handler requires the use of NMI while in SMM.."
05:01:29 <bcos_> The part I was refering to is the third paragraph of that section, starting with "A special case can occur if an SMI handler nests inside an NMI handler"
05:02:26 <virtx> is there some difference on intel in long mode between syscall and sysenter?
05:04:46 <bcos_> virtx: Yes, mostly SYSENTER switches to a "known good" stack and avoids a lot of issues
05:05:07 --- join: t3hn3rd (~Logic_Bom@cpc91224-cmbg18-2-0-cust219.5-4.cable.virginm.net) joined #osdev
05:05:29 <virtx> so they have to be handled differently in kernel
05:05:30 <bcos_> ..and SYSENTER is a little faster because it does less (until you start adding a whole pile of overhead in the hope of avoiding all the problems that not switching stacks causes)
05:05:40 <bcos_> Yes
05:05:57 <bcos_> Also note that AMD don't support SYSENTER in 64-bit code, so...
05:06:37 <doug16k> don't you mean syscall is faster because it does less?
05:06:38 --- join: tacco| (~tacco@i59F5FD54.versanet.de) joined #osdev
05:06:43 <Vercas> ^
05:06:43 --- quit: t3h_n3rd (Ping timeout: 264 seconds)
05:06:46 <bcos_> D'oh - yes
05:07:15 <Vercas> bcos_: Though would you recommend adding 64-bit sysenter support to a kernel?
05:07:18 <virtx> bcos_: yes, I know, I am talking about intel only
05:08:03 --- join: t3h_n3rd (~Logic_Bom@cpc91224-cmbg18-2-0-cust219.5-4.cable.virginm.net) joined #osdev
05:09:40 --- quit: t3hn3rd (Ping timeout: 265 seconds)
05:10:11 <bcos_> Vercas: If the kernel's API is buried in a dynamically linked/shared library (C standard library, "kernel.dll", whatever) and is never used directly by user-space (which is what all good OS's do anyway); then it'd be relatively easy to just have 2 different libraries (one that SYSENTER and another that doesn't) and relatively easy for kernel to support "anything" (possibly including using invalid opcode exception to emulate SYSENTER
05:10:13 <bcos_> on CPUs that don't support it, etc)
05:11:06 <bcos_> For SYSCALL, depending on the kernel and its intented purpose, I'd be tempted to never support SYSCALL at all
05:11:12 <Vercas> Oh?
05:11:14 --- quit: SlyFawkes (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
05:11:33 <doug16k> funny that the discussion went into syscall after the NMI stuff. syscall has a problem with an NMI occurring after syscall, and before swapgs. an interrupt handling code path can't rely on the return cs to indicate whether swapgs is necessary
05:12:09 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
05:12:11 <Vercas> doug16k: Hah, yeah that's shitty. But it's no rocket science to handle.
05:12:31 <Vercas> The NMI handling code can just check if the current GS base is in kernel space or not.
05:12:57 <bcos_> Vercas: On older CPUs (that only have "swapgs"), how does NMI handling code check GS base?
05:13:18 <bcos_> - you have to read an MSR and that causes major performance suckage
05:13:20 <Vercas> bcos_: Uh... What do you mean, only `swapgs`? No MSRs?
05:13:24 <Vercas> Oh.
05:13:28 <Vercas> I'm talking about the MSRs.
05:13:47 <bcos_> Yeah - MSRs are serialising - cost "tens of cycles" minimum
05:14:01 <Vercas> Well, depends on the MSR.
05:14:02 <doug16k> older cpus that don't have rdgsbase
05:14:13 <Vercas> doug16k: I know, none of mine have it. :l
05:14:22 <doug16k> :O
05:14:37 <Vercas> My latest is i7-4720HQ
05:16:42 <bcos_> Of course machine check can interrupt NMI handler (and NMI can interrupt machine check handler); and SYSCALL can mean your stack is dodgy (on top of the "has swapgs been done or not" issue); and now there's the "mov ss; .." problem on top of all that, and...
05:17:31 <doug16k> lol, it's a mess isn't it
05:17:36 <bcos_> ..it all adds up into a major cluster-bork where you can't solve all the problems because the solution for one makes another worse
05:17:47 * bcos_ nods
05:20:28 <Vercas> Well, you can use ISTs to put the NMIs on their own stack.
05:20:37 --- quit: Lowl3v3l (Quit: Leaving.)
05:20:44 <bcos_> And now we're back to "NMI can nest"...
05:20:57 <Vercas> Which has solutions.
05:21:10 <bcos_> It does?
05:21:13 <SGautam> Why couldn't DOS work with complex numbers
05:21:16 <doug16k> is it reasonable to expect an SMI handler to use NMI though? why would it?
05:21:17 <Vercas> Not elegant solutions, but solutions nevertheless.
05:21:20 <SGautam> Because it ran under real mode
05:21:21 <SGautam> :D
05:22:16 <doug16k> is it that somewhere someone used iretq in the smi code and unknowingly caused nmi to unmask?
05:22:35 <bcos_> Vercas: NMI occurs, then SMI occurs before the NMI handler can execute anything and the SMI unblocks NMI, then a second NMI occurs and trashes the stack of the first NMI handler (because someoone thought IST would help), and now you're totally screwed before you can execute one single instruction
05:23:03 <Vercas> Why?
05:23:14 <bcos_> Which why?
05:23:19 <Vercas> "before the NMI handler can execute anything"
05:23:28 <Vercas> So before I can do anything that can be fucked up by being interrupted?
05:23:36 <ljc> hey is there a typo here? `#if defined(__linux__)` should be !defined ? unless i'm missing something https://wiki.osdev.org/Bare_bones
05:23:38 <bslsk05> ​wiki.osdev.org: Bare Bones - OSDev Wiki
05:24:18 <doug16k> ljc, it's not an error. it is insisting that you use a cross compiler. __linux__ won't be defined in a cross compiler
05:24:20 --- join: vmlinuz (~vmlinuz@2804:431:f724:14c7:6af4:4a58:66f9:6153) joined #osdev
05:24:20 --- quit: vmlinuz (Changing host)
05:24:20 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
05:24:38 <ljc> ok
05:24:47 <glauxosdever> jlc: It's correct
05:24:47 <doug16k> it will error if you use your (linux) system compiler
05:25:29 <ljc> might get the cross compilers on the wiki then, ubutu doesn't have an i386 gcc
05:25:29 <bcos_> Vercas: In theory; yes. If you use IST for NMI then your CPU can trash first NMI handler's stack before any instruction (in the NMI handler) is executed. In practice it's a lot harder to guess what will happen on which CPU (it depends a little on how you fell like interpretting the words "at instruction boundaries")
05:25:55 --- join: SlyFawkes (5166c138@gateway/web/cgi-irc/kiwiirc.com/ip.81.102.193.56) joined #osdev
05:27:19 <bcos_> Vercas: Also in practice the probability of the timing being "exactly bad" is extremely low. Most people just give up and say "well, maybe the OS will just plain crash, LOL!" because it's too hard to guarantee it works in all possible cases
05:28:43 --- join: zeus1 (~zeus@197.239.6.21) joined #osdev
05:28:45 <Vercas> bcos_: Yeah, but unlikely doesn't mean impossible.
05:29:22 <doug16k> in software, unlikely is almost equivalent to inevitable
05:29:35 <Vercas> I just spent the last month at work debugging a heisenbug that can literally only happen when a thread is interrupted exactly after one instruction, while another thread keeps running and executes the same instruction right before the first one...
05:30:43 <doug16k> yeah, I had a 3 instruction race window where a problem could happen in my context switch. it took about 5 seconds for it to occur :D
05:31:05 <bcos_> Yes - not impossible, but we live in a world were people don't even insist on ECC to save themselves the price of a cup of coffee, so...
05:31:27 --- quit: grumble (Read error: Connection reset by peer)
05:31:57 * doug16k has ECC
05:32:01 <Vercas> bcos_: Heh, my workstation (a HP ProLiant DL360e) has got ECC memory.
05:32:08 <klange> "Why is my OS crashing when I maximize this virtualbox window...." because I'm a moron and didn't set the video memory high enough...
05:32:11 --- join: grumble (~grumble@freenode/staff/grumble) joined #osdev
05:32:40 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
05:32:54 <doug16k> klange, virtualbox has a fit if you write past the end of the framebuffer? nice
05:32:55 <Vercas> Soooo I finished all my current tasks at work and I'm in limbo.
05:33:07 <izabera> try to break something
05:33:50 <Vercas> No thanks, I'm taking pride in the fact that I haven't managed to introduce a single bug into our codebase since I started working here. :D
05:34:00 <izabera> no i mean fuzz test your things
05:34:04 <doug16k> Vercas, spend the time writing some automation for something tedious
05:34:09 <Vercas> izabera: I did! Everything.
05:34:22 <Vercas> doug16k: Already did.
05:34:40 <Vercas> Most tedious task is text mining logs. Wrote a C# app to do it for me.
05:34:55 <Vercas> It even pulls them from the various stores and test farms.
05:36:20 <doug16k> SGautam, :D
05:36:36 <Vercas> I can even look inside archives found in those places... And it's recursive.
05:37:21 <SGautam> i crack the best puns, I know.
05:38:03 <glauxosdever> SGautam: Do you have another one?
05:38:18 * Vercas grabs the popcorn.
05:38:38 <SGautam> why can't the German drive his car on the motorway
05:38:48 <SGautam> because it's autobanned.
05:38:57 --- join: t3hn3rd (~Logic_Bom@cpc91224-cmbg18-2-0-cust219.5-4.cable.virginm.net) joined #osdev
05:38:59 <glauxosdever> lol
05:39:04 * Vercas should've expected that, but he did not.
05:39:19 <xenos1984> oh c'mon...
05:39:27 * xenos1984 is German
05:39:29 <xenos1984> :D
05:39:29 <Vercas> inb4 xenos1984 is Ge--
05:39:30 <Vercas> Lol.
05:40:41 <glauxosdever> Why couldn't Bach drive his car on the motorway?
05:41:01 <glauxosdever> Because he would drive bachwards
05:42:04 --- quit: t3h_n3rd (Ping timeout: 268 seconds)
05:43:44 <doug16k> oh man I hate ubuntu 18.04 LTS. sometimes I have to reboot to get it to detect my usb headset :(
05:43:50 <doug16k> why oh why didn't I wait for the .1 release
05:43:58 * Vercas throws brownies at glauxosdever.
05:44:16 <Vercas> doug16k: What have they managed to fuck up this time? :0
05:44:23 <Vercas> USB hotplug? :D
05:44:31 <SGautam> what's a Spartan's favourite activity?
05:44:34 <SGautam> cursing at hens
05:44:47 <SGautam> (get it?)
05:44:55 <Vercas> We geddit.
05:46:11 <doug16k> Vercas, yes. and I get a flood of USB errors: https://gist.github.com/doug65536/1c852983a3385071f28048828d94d239
05:46:14 <bslsk05> ​gist.github.com: gist:1c852983a3385071f28048828d94d239 · GitHub
05:46:38 <Vercas> Wow.
05:46:44 <Vercas> That is impressive.
05:47:09 <glauxosdever> Well done, Ubuntu
05:47:58 <doug16k> do_IRQ: 5.34 No irq handler for vector <-- really? which IRQ? which vector? what is 5.34? D:
05:48:46 <SGautam> maybe you didn't catch the latest feature in x86
05:48:53 <SGautam> floating point interrupt indexes
05:49:20 <ljc> hey so i followed the barebones guide but grub can't find the multiboot header
05:49:34 <doug16k> SGautam, sure, but shouldn't it be 5.33999999999999985789?
05:50:03 <ljc> the magic number is at 0x00100000 (from radare2), well outside of the first 8KiB
05:50:35 --- join: Lowl3v3l (~Lowl3v3l@141.35.23.133) joined #osdev
05:52:09 --- quit: jakogut (Remote host closed the connection)
05:52:18 <SGautam> hahahah doug16k
05:52:23 <SGautam> that's a good one
05:52:31 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
05:54:11 --- quit: doug16k (Remote host closed the connection)
05:56:17 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
05:56:42 <ljc> ok i'll continue tomorrow, way too tired atm
05:56:42 <SlyFawkes> ljc I'm new to this but I think that means your linker script isn't putting the multiboot header in the right place?
05:56:53 <ljc> hm 1 sec
05:59:27 --- quit: Lowl3v3l (Ping timeout: 255 seconds)
06:00:51 --- quit: jakogut (Quit: jakogut)
06:01:16 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
06:02:28 <ljc> yea, you're right
06:02:28 <ljc> the magic number is at 1MiB
06:02:38 <ljc> and the linker script in the wiki has ". = 1M;" at the top
06:04:01 <SlyFawkes> that's where it should be though? doesn't x86 reserve the first 1MiB for stuff
06:05:11 --- join: Lowl3v3l (~Lowl3v3l@141.35.23.133) joined #osdev
06:05:22 --- quit: jakogut (Client Quit)
06:05:29 <sortie> Some of the first 1 MiB is just regular memory
06:05:41 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
06:05:43 <sortie> See the memory map page on the wiki
06:06:53 --- join: attah (~attah@h-155-4-135-114.NA.cust.bahnhof.se) joined #osdev
06:07:07 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
06:08:27 <SlyFawkes> sweet hadn't seen that page yet cheers
06:09:54 --- quit: Lowl3v3l (Remote host closed the connection)
06:10:49 --- quit: magnificrab (Ping timeout: 240 seconds)
06:11:16 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
06:11:40 --- quit: aalm (Ping timeout: 268 seconds)
06:15:25 <ljc> i think the linker script is okay
06:16:18 <ljc> derp, mb
06:16:56 <SlyFawkes> hmm?
06:17:28 --- quit: JusticeEX (Ping timeout: 260 seconds)
06:18:08 --- quit: zeus1 (Ping timeout: 250 seconds)
06:18:28 <ljc> i thought i saw a tilde and it's a minus ;d
06:20:22 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
06:22:19 --- join: toddw (~toddw@unaffiliated/toddw) joined #osdev
06:22:41 --- quit: toddw (Client Quit)
06:23:54 --- join: Lowl3v3l (~Lowl3v3l@141.35.23.133) joined #osdev
06:25:09 --- join: toddw (~toddw@unaffiliated/toddw) joined #osdev
06:30:06 --- quit: Lowl3v3l (Quit: Leaving.)
06:40:49 --- quit: promach__ (Ping timeout: 240 seconds)
06:42:17 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
06:46:24 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
06:49:49 --- quit: magnificrab (Ping timeout: 240 seconds)
06:52:12 --- quit: toddw (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:53:24 --- join: toddw (~toddw@unaffiliated/toddw) joined #osdev
06:54:27 --- quit: root1 (Quit: WeeChat 1.5)
06:57:46 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
06:59:07 --- join: NaNkeen (~nankeen@115.164.80.206) joined #osdev
07:01:18 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
07:02:28 --- join: Asu (~sdelang@128.17.136.77.rev.sfr.net) joined #osdev
07:07:27 --- join: peterbjo1nx (~peterbjor@arachne.peterbjornx.nl) joined #osdev
07:09:10 --- join: m_t (~m_t@p5DDA31EE.dip0.t-ipconnect.de) joined #osdev
07:10:04 --- quit: xenos1984 (Quit: Leaving.)
07:11:26 --- quit: epony (Remote host closed the connection)
07:11:37 --- quit: ALowther (Remote host closed the connection)
07:11:43 --- join: epony (~nym@79-100-134-61.ip.btc-net.bg) joined #osdev
07:12:45 --- join: zeus1 (~zeus@197.239.7.54) joined #osdev
07:14:24 --- quit: m_t (Quit: Leaving)
07:16:49 --- quit: magnificrab (Ping timeout: 240 seconds)
07:17:13 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
07:20:06 --- quit: vmlinuz (Ping timeout: 250 seconds)
07:22:34 --- quit: SGautam (Quit: Leaving)
07:23:24 --- quit: ljc (Quit: ayy)
07:23:37 --- quit: Lucretia (Read error: Connection reset by peer)
07:23:45 <doug16k> ljc, you might need -z max-page-size=4096 in your linker options (-Wl,-z,max-page-size=4096 if using gcc to link)
07:26:19 <doug16k> it is possible that ld is configured to align sections to large (file offset) alignments to make it possible to file map sections with large pages. setting it to 4096 avoids those large alignments
07:27:09 --- join: Lucretia (~laguest@pdpc/supporter/active/lucretia) joined #osdev
07:37:46 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
07:37:55 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
07:40:00 --- join: janemba (~janemba@unaffiliated/janemba) joined #osdev
07:44:02 --- quit: zhiayang_ (Quit: ZNC 1.8.x-nightly-20180502-d16817b0 - https://znc.in)
07:44:55 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
07:46:06 --- quit: zhiayang (Client Quit)
07:47:27 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
07:49:09 --- quit: constant (Quit: Found 1 in /dev/zero)
07:57:48 --- quit: magnificrab (Ping timeout: 250 seconds)
08:02:21 --- quit: peterbjo1nx (Remote host closed the connection)
08:02:39 --- quit: doug16k (Read error: Connection reset by peer)
08:02:40 --- join: m3nt4L (~asvos@2a02:587:a023:f000:3285:a9ff:fe8f:665d) joined #osdev
08:03:42 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
08:05:30 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
08:06:03 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
08:07:16 --- quit: ALowther (Remote host closed the connection)
08:13:28 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
08:16:27 --- quit: virtx (Quit: Page closed)
08:17:11 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
08:23:03 --- join: SGautam (~GautamS@unaffiliated/gautams) joined #osdev
08:23:34 <SGautam> I come with another good pun
08:24:53 <SGautam> why did the Swede lose the race
08:25:01 <SGautam> because he could not cross the Finnish line
08:25:35 * Vercas applauds.
08:26:14 --- quit: toddw (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:27:07 --- quit: promach__ (Ping timeout: 256 seconds)
08:27:30 --- quit: elevated (Quit: bye)
08:28:45 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
08:28:49 --- quit: elevated (Client Quit)
08:29:54 * lachlan_s also applauds
08:30:43 --- join: gareppa (~gareppa@unaffiliated/gareppa) joined #osdev
08:30:45 <SGautam> i wish there was an IRC channel where i could discuss my puns and get reviews
08:31:12 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
08:31:27 --- quit: gareppa (Client Quit)
08:31:52 --- join: gareppa (~gareppa@unaffiliated/gareppa) joined #osdev
08:32:28 --- quit: gareppa (Remote host closed the connection)
08:32:49 --- quit: `Guest00000 (Ping timeout: 240 seconds)
08:33:10 --- quit: elevated (Client Quit)
08:34:04 --- join: `Guest00000 (~user@37.113.180.43) joined #osdev
08:34:43 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
08:35:26 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
08:38:11 --- quit: glauxosdever (Quit: leaving)
08:38:24 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
08:41:31 --- quit: jordyd (Quit: Bye!)
08:43:29 <SGautam> why did Poland replace his furniture
08:43:35 <SGautam> because they had lost their polish
08:48:52 --- join: AntiSpamMeta2 (asm@AntiSpamMeta/.) joined #osdev
08:48:52 --- quit: AntiSpamMeta (Killed (wolfe.freenode.net (Nickname regained by services)))
08:48:52 --- nick: AntiSpamMeta2 -> AntiSpamMeta
08:50:26 --- join: jordyd (~jordyd@pampanic/co-maintainer/jordyd) joined #osdev
08:54:08 --- join: EvanCarroll (~ecarroll@172.58.103.88) joined #osdev
08:54:41 --- join: mra90 (~Martin@host-85-202-159-241.sta.tvknaszapraca.pl) joined #osdev
08:58:55 --- quit: `Guest00000 (Ping timeout: 264 seconds)
09:04:22 --- quit: Kimundi__ (Read error: Connection reset by peer)
09:04:29 --- join: Kimundi__ (~Kimundi@i577A9653.versanet.de) joined #osdev
09:11:19 --- quit: attah (Remote host closed the connection)
09:11:48 --- quit: t3hn3rd (Read error: Connection reset by peer)
09:18:26 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
09:19:27 --- quit: Kimundi__ (Read error: Connection reset by peer)
09:19:56 --- join: Kimundi__ (~Kimundi@i577A9653.versanet.de) joined #osdev
09:22:47 --- quit: ALowther (Ping timeout: 248 seconds)
09:26:58 --- join: oaken-source (~oaken-sou@194.152.148.167) joined #osdev
09:28:41 <lkurusa> #osdev-puns
09:33:37 --- join: `Guest00000 (~user@37.113.180.43) joined #osdev
09:34:55 --- quit: promach__ (Ping timeout: 264 seconds)
09:44:41 --- quit: NaNkeen (Ping timeout: 260 seconds)
09:47:12 --- quit: Kimundi__ (Read error: Connection reset by peer)
09:47:32 --- join: Kimundi__ (~Kimundi@i577A9653.versanet.de) joined #osdev
09:48:07 --- quit: magnificrab (Ping timeout: 268 seconds)
09:48:46 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
09:50:14 --- join: toddw (~toddw@unaffiliated/toddw) joined #osdev
09:52:33 --- quit: doug16k (Remote host closed the connection)
09:52:42 --- quit: zhiayang (Quit: ZNC 1.8.x-nightly-20180502-d16817b0 - https://znc.in)
09:53:39 --- quit: drakonis (Ping timeout: 255 seconds)
09:53:45 --- quit: magnificrab (Remote host closed the connection)
09:54:08 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
09:54:11 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
09:55:14 --- quit: zhiayang (Client Quit)
09:55:39 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
10:12:18 --- quit: m3nt4L (Remote host closed the connection)
10:12:55 --- join: dbittman_ (~dbittman@apollo.soe.ucsc.edu) joined #osdev
10:12:56 --- nick: dbittman_ -> dbittman
10:15:09 --- quit: toddw (Ping timeout: 246 seconds)
10:19:34 --- quit: Affliction (Remote host closed the connection)
10:20:22 --- join: Affliction (affliction@2600:3c01::13:ffff) joined #osdev
10:21:28 --- quit: port443 (Quit: Candlejack has no power he)
10:21:56 * geist yawns
10:22:02 --- join: port443 (~wizardmin@mtndewcode.red) joined #osdev
10:23:03 <lachlan_s> Morning geist
10:24:39 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:26:57 <geist> gmorning
10:27:13 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
10:27:46 <lachlan_s> What's your timezone? Seems pretty late for the us
10:29:56 --- join: zesterer (~zesterer@cpc138506-newt42-2-0-cust207.19-3.cable.virginm.net) joined #osdev
10:32:46 --- join: oldtopman (~oldtopman@unaffiliated/oldtopman) joined #osdev
10:33:44 --- join: hmmmmm (~sdfgsf@pool-72-79-167-21.sctnpa.east.verizon.net) joined #osdev
10:36:12 <geist> 10:30am
10:36:36 <geist> i get up late
10:36:54 <lachlan_s> West coast?
10:38:02 <geist> yep,seattle
10:38:16 --- join: masoudd (~masoudd@5.115.237.66) joined #osdev
10:38:22 <lachlan_s> Cool cool
10:38:35 <lachlan_s> How does your work let you get up so late?
10:38:46 <lachlan_s> Flexible hours at Google?
10:40:41 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
10:40:55 <bcos_> I think, if you sleep at your desk each night, few people notice that you haven't woken up yet
10:46:06 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
10:46:30 <geist> yeah no one cares when you're at the office as long as you get work done
10:49:13 --- join: migmatite (~migmatite@2a00:23c4:61a:3600:ec98:1122:3d07:296c) joined #osdev
10:50:35 <geist> it's all personal responsibility to do what needs to be done, and be available when appropriate
10:51:11 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
10:53:56 --- join: aalm (~aalm@37-219-119-194.nat.bb.dnainternet.fi) joined #osdev
10:55:53 <lachlan_s> That's cool
10:56:14 <lachlan_s> Do you have meetings you have to go to?
10:56:49 <geist> not a lot no. usually only 1-2 a week
10:56:54 --- quit: light2yellow (Quit: light2yellow)
10:56:54 <geist> and usually in the afternoon
10:58:04 <lachlan_s> Nice, that's unusual in the industry, I feel
10:58:24 <geist> not a lot of meetings is fairly unusual even within google
10:59:05 <lachlan_s> How'd you get lucky then?
10:59:13 --- quit: migmatite (Quit: migmatite)
10:59:31 <geist> our team just doesn't do a lot of meetings
10:59:41 <geist> we're still developing a lot of stuff, less to meet over
10:59:47 <geist> it's heads down get it done
11:00:27 <lachlan_s> Cool
11:00:33 <SGautam> huh so Google everywhere is like that
11:00:38 <geist> management is pretty hands off, most of the team are senior folks that are pretty self driven
11:00:46 <geist> that's not at all what i'm saying SGautam
11:00:52 <geist> i told you it's fairly unusual even within google
11:00:54 <lachlan_s> Yeah, I want to try working at google at some point. You hear a lot of good things and bad things
11:01:09 <SGautam> some of my seniors tell me how open the environment is in Google's offices compared to more conservative workplaces
11:01:18 <geist> yes. that is true
11:01:43 <geist> but that's fairly standard across most of silicon valley style tech now
11:01:43 <lachlan_s> Once I get out of school, that is
11:02:36 <SGautam> i'd consider joining google if i hadn't had to move to bangalore
11:02:44 <lachlan_s> You had to move?
11:02:47 <lachlan_s> family?
11:02:54 <SGautam> err
11:03:06 --- quit: booyah (Remote host closed the connection)
11:03:37 <geist> google is definitely better than most places to work for, for sure
11:03:51 <geist> i have now worked here longer than any other place (a bit over 5 years)
11:03:56 <geist> so i'll probably be here forever
11:04:05 <SGautam> lachlan_s: bangalore is like mini silicon valley in india
11:04:19 --- quit: zeus1 (Ping timeout: 264 seconds)
11:04:27 <geist> but. it can be difficult, especially for folks like me with fairly powerful performance anxiety
11:04:38 <SGautam> hm?
11:04:43 <geist> since you're surrounded by folks that are very very intelligent
11:04:44 <SGautam> can you elaborate?
11:04:46 <SGautam> ah
11:04:48 <SGautam> right
11:05:06 <geist> it pushes you but it can burn you out
11:05:17 <geist> at least it's my main life challenge, finding a good balance there
11:05:23 <lachlan_s> Impostor syndrome is pretty common among programmers
11:05:30 <SGautam> i had that experience in high school, classes were separated by grades
11:05:39 <SGautam> i used to think i was pretty intelligent, well shit.
11:06:02 <geist> indeed. i have fairly powerful impostor syndrome, and the cluster of problems that come with it
11:06:16 <lachlan_s> I'd definitely say I do too
11:06:25 <geist> some of which can be harnessed for powerful use, but finding the right balance on a day to day basis is difficult
11:06:51 <SGautam> everybody does, i would think impostor syndrome is definitely one of the things that has motivated me more than anything else
11:07:05 <SGautam> seeing that others can accomplish something, so why can't I
11:07:08 <geist> indeed. it's the cluster of destructive things that come with it that are hard to shake
11:07:13 <lachlan_s> I try to use it as motivation to be better
11:07:23 <geist> like driving yourself into the ground, not being able to deal with something not being *perfect*
11:07:30 <geist> taking failures personally, etc
11:08:11 <geist> http://interactions.acm.org/archive/view/may-june-2018/is-there-a-fix-for-impostor-syndrome is a nice little blurb, written by someone on the team actually
11:08:13 <bslsk05> ​interactions.acm.org: Is there a fix for impostor syndrome? | ACM Interactions
11:08:33 <geist> actually bought the book referenced there and am reading through it
11:08:52 <SGautam> geist: well i keep reminding myself that i only see those people when they're at their best, the good part is that i've got to see some people who were quite capable and intelligent but fail a lot as well
11:08:57 <geist> the file attributes in the bullet list a little ways down is really accurate
11:09:14 <geist> s/file/five
11:09:55 <lachlan_s> Autocorrect knows you too well
11:10:04 <geist> so i know about this, and i'm fairly good at mentally handling it, especially since almsot every high performing person i know of feels the same well
11:10:39 <geist> but i still have the baseline anxiety and stress that is harder to deal with, since it's my biochemical systems that are doing that, and they're harder to directly control
11:11:10 <lachlan_s> I recently got on some light antidepressants and it actually helps a lot.
11:11:27 <geist> ie, once your body starts producing adrenaline too much it's hard to get it to stop, etc
11:11:29 --- join: dafna (4d7e3934@gateway/web/freenode/ip.77.126.57.52) joined #osdev
11:11:35 <geist> yah, i suspect so
11:11:44 <lachlan_s> Lets me ignore the physical things going wrong
11:11:53 <lachlan_s> At least chemically
11:11:59 <geist> yah
11:12:28 <dafna> hi, I'm experimenting with a real time os called unikraft
11:12:36 <geist> but yeah i can trace this stuff way back to those first few years at silicon valley, where i was in completely over my head
11:12:56 <geist> that's when i did a lot of the really good early osdev, because i was completely driven to learn learn learn and get better
11:13:23 <geist> but then once you end up as the 'expert' after 5 or 10 years, you still feel like a fraud
11:13:28 <lachlan_s> It is super cool that you were able to turn it into a career
11:13:44 <geist> oh 100%. but it may ultimately be unhealthy
11:13:48 <lachlan_s> And, as you say, be the 'expert'
11:13:49 <geist> but then probably everything is.
11:13:55 <lachlan_s> Life is unhealthy
11:13:59 <geist> exactly.
11:14:03 <dafna> I notice that when I divide by 0, if the division error trap is not implemented then the os eneters an endless loop of rebooting
11:14:30 <geist> dafna: that makes sense
11:14:37 <dafna> but if I do implement an interrupt handler for it then the execution keep running after the instruction that caused the interrupt
11:14:45 <geist> good
11:14:57 --- join: light2yellow (~l2y@185.220.70.134) joined #osdev
11:15:00 <dafna> yes, that's the expected behaviour ?
11:15:12 <lachlan_s> Ya
11:15:20 <dafna> that the cpu goes back to the interucion AFTER the one causing the interrupt ?
11:15:33 <geist> i forget. what does the intel/amd manual say?
11:16:05 <lachlan_s> Oh, hmm
11:16:14 <lachlan_s> It should repeat it, I think
11:16:31 <geist> yeah i'd generally assume it wouldn't, because the os probably wants to inspect the instruction
11:16:43 <geist> and forcing the kernel to unwind and find the previous instruction is a drag
11:17:04 <geist> most exceptions like that leave IP pointing at the instruction that caused it
11:17:18 <lachlan_s> It's need to embed a disassembler in that case
11:17:25 <pounce> Does somebody have a OS with a nice interrupt-driven serial implementation that they run under qemu? @w@
11:17:26 <graphitemaster> all faulting exceptions leave IUP pointing at the faulting instruction
11:17:30 <geist> yep. x86 is annoying like that
11:17:31 <graphitemaster> *IP
11:17:37 <lachlan_s> s/it's/it'd
11:18:01 <geist> pounce: zircon is, LK i think is RX IRQ driven
11:18:02 <graphitemaster> trap instructions leave it at 1 after, and aborts just reset the machine
11:18:21 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:18:33 <pounce> I might need one to test this patch wit
11:18:37 <pounce> with*
11:18:56 --- quit: zesterer (Ping timeout: 265 seconds)
11:19:13 <lachlan_s> geist: being honest, you're career is pretty inspirational to someone like me, who wants to do osdev as a career
11:19:34 * pounce nods
11:20:12 <graphitemaster> osdev used to be the hot shit back during dem days
11:20:22 <graphitemaster> webdev took over
11:20:38 <graphitemaster> now oses are just websites with a billion lines of js
11:21:46 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
11:21:49 <epony> graphitemaster you seem to be living in a pretty unhappy universe if you think that
11:22:17 <epony> I say it's the dumbest line of the year.
11:22:48 <SGautam> osdev isn't cool now
11:23:03 <lachlan_s> It's cool, it's just not hip
11:23:08 <SGautam> agree
11:23:26 --- quit: banisterfiend (Client Quit)
11:23:36 <graphitemaster> Take a look at Window 10. They have an HTTP server in the kernel. WCMI is literally just a glorified REST api, almost all Windows 10 store apps are Typescript or Javascript running against window.ui.core directly from a node.js provider, services are specified using json.
11:23:39 <geist> yep. i live a charmed life. i'm a one trick pony
11:23:49 <geist> but, there is *always* a demand for folks that do low level hackery
11:24:07 <geist> perhaps it's a tiny segment of the industry, but it's well respected, pays well, so can't complain
11:24:47 <geist> so sure, by focusing on low level/osdev i cut myself off from most of the webdev and whatnot that is out there, but so it goes
11:25:05 <geist> i'm okay with that decision
11:25:18 <SGautam> MS has been pushing HoloLens pretty hard
11:25:23 <pounce> Is using json to communicate bad? I work on a big C project that does a lot of its IPC with json
11:25:46 <graphitemaster> parsing json is non-trivial and also quite expensive for low-latency situations.
11:25:48 <geist> i dunno, as far as random ways to serialize stuff and deserialize it, there are probably worse
11:25:58 <geist> but yeah it depends a lot on what its used for
11:26:28 <lachlan_s> json is complicated to parse
11:26:30 <graphitemaster> I think most serious places use protobuf for IPC
11:26:37 <lachlan_s> A binary serialization is faster
11:26:51 <geist> yah capn'proto is a fave of mine
11:26:56 <pounce> is DBUS serialized in binary?
11:27:12 <epony> graphitemaster If you thing the UNIX philosophy is alright, and found out it's getting copied out poorly in web development, that's because the model is good and programmers employed in web development are not capable of more original endeavours. But if you say that's where it happens, you obviously have something on your glasses.
11:27:25 <epony> *think*
11:27:42 <graphitemaster> webdevs are turning the frogs gay </troll>
11:28:00 <epony> graphitemaster your talk is nothing more than provocative.
11:28:12 <geist> epony: heh, you have discovered his secret
11:28:30 <graphitemaster> geist, capn'proto is that even faster one, but you should try flatbuffers, which is an even faster one.
11:28:41 <pounce> !!!patch working
11:29:28 <SGautam> uhh you got the punctuation reversed mate
11:29:39 <pounce> patch working!!!
11:30:01 <lachlan_s> Nah, both sides
11:30:09 <graphitemaster> !!!patch!!!working!!!
11:30:18 <pounce> ^^^
11:30:39 <SGautam> um
11:30:47 <graphitemaster> personally, when I write code and am feeling really awful I'll use semicolons for indentation opposed to spaces or tabs
11:30:53 <SGautam> !!!Patch!!!is!!!working.!!!!
11:31:03 <SGautam> pounce: correct way is give up^
11:31:06 --- quit: zhiayang (Quit: ZNC 1.8.x-nightly-20180502-d16817b0 - https://znc.in)
11:31:09 <pounce> why graphite
11:31:25 <geist> thats;pretty;odd;
11:31:42 <pounce> four semicolons or eight semicolons >.>
11:31:46 <epony> graphitemaster It's what on your task list that matters.
11:32:10 <graphitemaster> 2.5 semicolons
11:32:18 <geist> ¡¡¡patch working!!!
11:32:20 <Amaan> A quarter colon?
11:32:21 <graphitemaster> you need to use the unicode one that is half-width
11:32:50 <graphitemaster> ;;
11:33:40 <pounce> double-width ZH semicolon
11:33:42 <lachlan_s> geist: plus, people know who you are
11:33:42 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
11:33:47 <lachlan_s> Just in general
11:33:53 <pounce> (plus a greek-comma mixed in every once and a while)
11:34:08 <geist> heh, i am now reading about why spanish has the inverted marks and most other languages dont
11:34:31 <epony> because intonation, dude
11:34:51 <geist> ah apparently it's pretty recent. started in 1754
11:35:04 <Amaan> Programming with insufficient tooling can be so frustrating
11:35:09 * Amaan wants to punch a wall
11:35:48 <pounce> geist: how would I test serial using zircon?
11:36:06 <geist> on qemu? build it and boot it, on qemu it starts a shell on the serial port
11:36:25 <geist> there's a script to automate the starting of qemu: ./scripts/run-zircon-x64
11:36:48 <pounce> ah nice. I'll do that
11:37:50 --- join: zeus1 (~zeus@197.239.7.54) joined #osdev
11:37:54 <dafna> so the fact that after divide error the program continue with the next instruction is quit a mystery
11:39:00 <lachlan_s> dafna: What does your interrupt handler look like>?
11:39:11 <Ameisen> \o/
11:39:19 <Ameisen> I was able to get libc and libgcc building and linking with -flto
11:39:25 <Ameisen> that was an experiencew.
11:40:11 <graphitemaster> I was able to get libc and libgcc to build once, normally
11:40:14 <graphitemaster> that was an experience
11:40:38 <Ameisen> heh
11:40:46 <epony> in a virtual machine ran in a flaky browser, right.
11:40:46 <Ameisen> In this case I was running into odd issues here and there
11:40:55 <Ameisen> ended up basically eliminating _all_ flags the libc and libgcc build system added
11:40:58 <Ameisen> that could conflict
11:41:10 <Ameisen> also made sure it _never_ emitted -g other than -g0, as -g isn't compatible with LTO
11:41:18 <graphitemaster> I think the configure scripts and compiler output for a full gnu toolchain outputs more lines of code than the projects themselves
11:41:50 <Ameisen> indeed
11:41:55 <Ameisen> and all the patches I have to add to make it do what I want.
11:42:04 <Ameisen> their configure scripts aren't necessarily meant to play nicely with what you want to do
11:42:12 <Ameisen> their configure scripts aren't always meant to play nicely, period
11:42:27 <graphitemaster> "checking if host character type supports literals 'a', 'b', 'c'...."
11:42:44 <Ameisen> if only configure scripts were fully standardized.
11:42:51 <graphitemaster> for the entire UTF code page lol
11:42:52 <Ameisen> then it wouldn't take about as much time to configure as it would to build
11:42:59 <Ameisen> note - I'm also building under MSYS2
11:43:03 <Ameisen> which... adds a whole host of complexity
11:43:14 <graphitemaster> how many possible characters are there in unicode entierety?
11:43:49 <Ameisen> 'checking if host supports compiling C programs...'
11:43:52 <Ameisen> why even bother checking
11:43:52 <graphitemaster> accuming 17 planes, at 65536 characters a plane, that's 1114112 possible characters
11:43:56 <graphitemaster> *assuming
11:43:57 <Ameisen> if it doens't support it, we'll find out pretty darned fast
11:44:05 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
11:44:36 <lachlan_s> Yeah, there must be a better way of checking if it supports certain c features
11:44:51 <Ameisen> If only the C compiler had a way to report features
11:44:53 <Ameisen> maybe using macros
11:45:28 --- join: hmmmmmm (~sdfgsf@pool-72-79-167-28.sctnpa.east.verizon.net) joined #osdev
11:46:00 <lachlan_s> Or if you could just query the compiler using the cli
11:46:38 --- join: dennis95 (~dennis@i577BCED9.versanet.de) joined #osdev
11:47:07 <Ameisen> yeah
11:47:15 --- quit: SGautam (Quit: Leaving)
11:47:15 <Ameisen> the configure scripts tend to have issues in MSYS2
11:47:19 <Ameisen> MSYS2 has a 'virtual' unxi path system
11:47:24 <Ameisen> /d/, for instance, points to D:/
11:47:34 <Ameisen> however, the file handling functions in the runtime do not handle this
11:47:43 <Ameisen> so #include "/d/..." doesn't work
11:47:59 <Ameisen> there are some configure scripts that expect absolute addresses, and break relative addresses (because of sed), and don't work at all with windows paths
11:48:05 <Ameisen> but then pass those absolute addresses to the configure script for testing for features
11:48:10 <Ameisen> so they were just breaking no matter what I did
11:48:12 <Ameisen> :|
11:48:54 --- quit: hmmmmm (Ping timeout: 265 seconds)
11:51:24 --- quit: awang__ (Ping timeout: 246 seconds)
11:52:19 <pounce> What should I do for the version_id of a new VMStateDescription ?
11:52:56 <dafna> lachlan_s: it seems that the interupt handler increase the intstruction pointer
11:53:08 <pounce> whoops wrong channel
11:53:18 <epony> graphitemaster I wonder what more original can you create with all those characters at your disposal today.
11:53:54 <Ameisen> I'm waiting for someone to write me an OS that will let me name my folders/files using zalgo
11:54:14 <Ameisen> cd š̛͇̣̤̣͈̫͙̲̟̺̜͎͎̝͈͈͎͕̪́ͤ̅͂͛̂͒̍̑̓͜y̘̻̪̹̥̞̩̹̜͚͓̳̮̤̎̆̽̇̂ͤ̍̋̄̉ͭͥ́̂ͪ̃̚͟͟͟ͅs̸̨̨̮͚͓̻̤͙̥͖͍̖̘̭̪͕̏̏̿̏̿̋ͣ͝t̵̛̩͍͉͙͈̙̫̤̅̍̉͊͛͒ͦͦ̐ͯ͊͌͒̂ͨȩ̧͇̝͚͉͚̦̜̽͑͋̑̈ͩ͊ͩ̉͌ͭ͑̿̌̈̈̀ͩm̢̡̢̭̣̦͖̗̰͈͕̬̤̝ͩͯͫ̓ͩ̆͒̓̍̓́͛͋̕͡
11:54:16 <graphitemaster> Ameisen, files and folders need to disappear
11:54:21 <graphitemaster> worst idea ever
11:54:37 <epony> graphitemaster Are you proposing something to replace them with?
11:54:37 <pounce> yeah, they're obviously all files >.>
11:54:47 <Ameisen> raindrops from the cloud
11:54:49 <graphitemaster> epony, yeah I have a much better alternative
11:55:03 <epony> graphitemaster Describe the idea and we'll see.
11:55:04 --- join: awang_ (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
11:55:32 <lachlan_s> dafna: post a gist of your interrupt handler
11:56:30 <epony> graphitemaster That's a long description churning..
11:56:36 <dafna> it's not currently online
11:57:07 <dafna> after the restore of the registers back to the program context , it increases the r10 register by 4
11:57:12 <lachlan_s> What about a pastebin or something?
11:58:15 <dafna> ok, a minute
11:58:36 <graphitemaster> epony, The gist of it is basically a "stream", you can read and write into them, except streams can be provided by applications (as custom read/write/seek), they cna also be provided by services (think sort of like how /dev works), the big difference of course is that streams can also have substreams (and further, so this giving you folders/directories), and the contents of a stream are not really contigious (since you can chose to
11:58:36 <graphitemaster> write into the middle of a stream, which is something files do not support without writing out the whole tail end of it)
11:58:41 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:59:26 <pounce> It works with zircon!
11:59:34 <dafna> lachlan_s: it's not all the code: https://pastebin.com/XLVhYmx1
11:59:35 <bslsk05> ​pastebin.com: .macro RESTORE_ALL movq (%rsp),%r15 movq 1*8(%rsp),%r14 movq 2*8(%rsp),%r13 - Pastebin.com
11:59:36 <epony> Can you carry a stream on your usb flash stick?
11:59:43 <dafna> just the relevant parts
11:59:55 <lachlan_s> graphitemaster: That sounds a little like the scheme idea that redox uses.
12:00:10 <lachlan_s> Whoops, pastebin is blocked on my network currently
12:00:15 <graphitemaster> epony, a stream can be dumped to raw data, in which case that can be stored, and copying it back out onto the host file system into some other stream, of course the usb thing itself could contain this stream file system
12:00:15 <dafna> I think i wrote it myself long time ago and forgot:)
12:00:18 <dafna> see line 51
12:00:37 <epony> graphitemaster So you basically are talking out of your imagination here.
12:00:46 <dafna> it's the line that I think cause the program to continue after the errounous instruction
12:00:46 <lachlan_s> dafna: Can you post it to https://ghostbin.com/?
12:00:47 <bslsk05> ​ghostbin.com: Ghostbin
12:01:04 <pounce> wait... I did ^C and it broke the kernel... is that supposed to happen?
12:01:11 --- join: zesterer (~zesterer@162.202.189.80.dyn.plus.net) joined #osdev
12:01:35 <graphitemaster> epony, not at all, it's basically at it's core a linked-list of data pages
12:01:44 <graphitemaster> I've implemented it before in alice
12:01:48 <graphitemaster> (my microkernel)
12:01:53 <dafna> https://ghostbin.com/paste/qe4tj
12:01:54 <bslsk05> ​ghostbin.com: qe4tj - Ghostbin
12:02:01 <dafna> not that interesting
12:02:04 <epony> Ah, those linked lists will get you some more appreciation all around.
12:02:17 <graphitemaster> what is your problem
12:02:32 <dafna> anyway it's line 51
12:02:39 <lachlan_s> Yeah, hmm
12:02:44 <epony> I'm picking up for the shitty opening line.
12:02:48 <lachlan_s> Does it work with #51 commented out?
12:03:32 <dafna> when 51 is not commented out then it's the behaiour I descreibed that the programm continues after the exception with the next instruction
12:03:49 <dafna> when 51 is in comment then the intrrupt handler is called forever
12:04:23 <dafna> I wrote it myself about a month ago and didnt documented it
12:04:24 --- quit: qeos (Read error: Connection reset by peer)
12:04:41 <dafna> now im waisting my time descovering what i did
12:04:53 <Amaan> Classic
12:05:00 <dafna> :)
12:05:09 <lachlan_s> Huh, thats what even weirder
12:07:23 --- join: qeos (~qeos@ppp91-79-242-242.pppoe.mtu-net.ru) joined #osdev
12:08:42 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
12:12:49 --- quit: ALowther (Ping timeout: 240 seconds)
12:13:50 --- quit: zhiayang (Quit: ZNC 1.8.x-nightly-20180502-d16817b0 - https://znc.in)
12:20:56 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
12:23:13 --- quit: awang_ (Ping timeout: 265 seconds)
12:24:43 --- join: akasei (~akasei@viscon.wataha.net) joined #osdev
12:26:19 --- join: awang_ (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
12:30:43 --- quit: awang_ (Ping timeout: 264 seconds)
12:31:19 --- join: awang_ (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
12:35:16 <Ameisen> I need to find a way to automatically parallelize these configure scripts
12:35:24 <Ameisen> this libc configure... calls ./configure for every multilib
12:35:29 <Ameisen> it spends like 40 minutes in configure
12:38:13 --- quit: rain1 (Quit: Leaving)
12:40:18 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:42:13 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
12:44:36 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
12:46:23 --- quit: magnificrab (Ping timeout: 256 seconds)
12:47:11 <dafna> hi, I change the code of the divide error handler to call a function cpu_halt at the end
12:47:48 <dafna> the cpu_halt is: __asm__ __volatile__("cli; hlt"); for (;;) ;
12:48:13 <dafna> in the assembly file I call it with "call cpu_init"
12:48:14 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
12:48:52 <dafna> but when dissassembly the o file with objdump it shows "callq c1 <error_entry+0xc1>"
12:50:56 <Ameisen> I want to know why GCC has the ability to place a general memory barrier, but no obvious way to place a memory barrier on just a specific address range
12:51:54 <bauen1> Is reading from video memory really that slow or is my memcpy just super slow ?
12:53:27 --- quit: awang_ (Ping timeout: 256 seconds)
12:54:47 <doug16k> Ameisen, barrier on an address range? that isn't how barriers work
12:55:37 <bcos_> bauen1: How much difference between do you think there is between "CPU's L1 cache bandwidth" and "PCI bus bandwidth" (where each write is more like a packet containing "header, address, payload and checksum")
12:56:00 --- join: awang_ (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
12:56:18 <doug16k> bauen1, reading video memory is particularly slow because the cpu has to wait for it. writes are faster because they can be posted to a queue
12:56:59 <doug16k> in a VM, reading and writing video memory is incredibly expensive because it traps to the hypervisor at each access
12:57:41 <doug16k> unless it is a string move like movsb/w/l/q, that will vmexit once for the whole transfer
12:59:05 <chrisf> what exactly are we calling "video memory" in this case?
12:59:25 <doug16k> chrisf, the framebuffer
13:00:09 <chrisf> doug16k: the legacy vga framebuffer?
13:00:22 <doug16k> no, any framebuffer
13:01:05 --- join: bemeurer (~bemeurer@gwnat-wifi-203.sbcc.edu) joined #osdev
13:01:12 <doug16k> kvm sets up the video memory range to raise a nested page fault at every access. when your code touches it, it vmexits and kvm emulates that instruction
13:01:47 <chrisf> oh, kvm insanity, OK.
13:02:18 <bcos_> Hrm
13:02:54 * bcos_ isn't too sure about that - KVM could just use plain normal RAM as the framebuffer
13:03:04 <doug16k> could?
13:03:30 <bcos_> ..and then just copy from that RAM to the window/screen every 1/60th of a second, without any VMexits
13:03:31 <doug16k> it doesn't
13:04:26 <bcos_> It should (unless it's a crappy VGA mode with bizarre "read/write mode" shenanigans)
13:04:26 <doug16k> here's how I know: I tried using SSE to optimize video memory accesses. when my code touched video memory, it trapped it and vmexited, and died with "emulation failed". I asked in #qemu and they explained that the emulation doesn't implement that instruction
13:04:48 <bcos_> Heh
13:05:08 <bcos_> Of course for open source crapware, "should" almost never means "does".. ;-)
13:05:36 <doug16k> now I am not asserting that it is always the case. but it is at least sometimes the case
13:05:59 <doug16k> rule of thumb: if linux doesn't do it, it doesn't work
13:06:12 <chrisf> presumably you fixed it and now it does
13:06:26 --- quit: magnificrab (Remote host closed the connection)
13:06:27 <doug16k> I stopped using SSE and yes it works fine now
13:06:33 <bcos_> Presumably, it doesn't work with SSE..
13:06:36 <chrisf> not what i meant.
13:06:39 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
13:07:52 <doug16k> bcos_, I think it does that sometimes. For sure all text mode accesses are trapped
13:08:09 <doug16k> even though it could do the same deferred update thing
13:08:21 <bcos_> Ah - text mode is one of the "crappy VGA mode with bizarre read/write mode shenanigans" cases
13:09:23 <doug16k> on the other hand, I did get over 1200 fps fullscreen clipped bitblt in vesa mode, so in that case it must be deferring
13:09:32 <bcos_> (specifically, you can write a value and read it back, and read back something very different to what you wrote)
13:09:49 <doug16k> bcos_, in text mode? how
13:10:28 <bcos_> There's a "read/write mode" register that controls where bits go
13:10:43 <bcos_> (and a few other registers on top of that)
13:10:43 <doug16k> it's not using that in text mode
13:10:50 <doug16k> you saying write modes affect text mode?
13:11:05 <doug16k> there's no bitplane crap happening is there?
13:11:07 <bcos_> Yes
13:12:06 <doug16k> yes it is using bitplanes in text mode?
13:13:49 <chrisf> incoming argument about exactly what configurations are "text mode"...
13:15:07 <bcos_> If I remember right, "default/standard VGA" uses one plane for "even addresses (character)" and the next plane for "odd addresses (attribute)", then a third plane for the font data
13:17:19 <bauen1> so to get a decent console I need to implement double buffering ?
13:17:52 <bcos_> bauen1: Yes - double buffering, and maybe look at your memcpy too (especially if it's a simple "for each byte" loop in C)
13:18:24 <bauen1> I've already optimised the memcpy, but this is gonna be good, give how I've just had to recover from a rm -rf .
13:20:50 <doug16k> bauen1, optimized how? rep movs?
13:21:55 <bauen1> yeah
13:22:09 <bauen1> Its a lot better then what I had
13:22:11 <doug16k> bcos_, yeah you're mostly right. it uses "odd/even addressing mode". even addresses access bitplane 0 and 2, odd addresses access bitplane 1 and 3. I've never touched that before because it is useless in VGA bitplane modes
13:22:29 <bcos_> I'd say that for copying buffer in RAM to frame buffer, there's 3 very different cases - integrated video (where writes are fast because they actually go to RAM and there isn't really any PCI bus involved), discrete video (where you really want to avoid doing writes as much as possible, and it can help to have a third buffer so you can do "if(old[pos] != new[pos]) { old[pos] = new[pos]; framebuffer[pos] = new[pos];}" to avoid writes
13:22:30 <bcos_> where the data didn't change); and virtual machines where "rep movsd" avoids lots of traps
13:23:49 <bcos_> doug16k: Yeah - it's a scary mess, and I wouldn't be too surprised if KVM (tries to) emulate the VGA registers properly (in case some old MS-DOS application does freaky things) ;-)
13:24:23 --- quit: bemeurer (Ping timeout: 248 seconds)
13:24:51 <bcos_> For normal LFB modes from (e.g.) VBE it shouldn't be a problem
13:26:23 <bcos_> Hmm - even VBE bank switched modes can/should work with "RAM pretending to be frame buffer" - hypervisor would just need to map the right pages in response to a bank switch
13:26:29 <doug16k> bauen1, yeah, string moves are really fast on modern processors, and drastically faster in VMs. I double-buffer text mode in my kernel, my scrolling is blazing fast
13:27:02 <bcos_> Text mode is probably only 4 KiB of data...
13:27:25 <doug16k> 8000+ traps per scroll
13:27:29 <bcos_> - switch to something like 1920*1600 with 32 bits per pixel and you're looking at ~1000 times more data
13:28:24 <doug16k> with dword accesses you could get it down to ~1000 vmexits per scroll. I like my implementation: 1 vmexit
13:29:42 <doug16k> I didn't only do it for performance, I also implement a text mode mouse cursor, and double buffering also made that trivially easier
13:35:07 --- join: rain1 (~rain1@unaffiliated/rain1) joined #osdev
13:36:16 --- quit: oaken-source (Ping timeout: 260 seconds)
13:39:36 --- quit: magnificrab (Remote host closed the connection)
13:39:52 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
13:58:52 --- quit: spare (Quit: leaving)
14:01:15 --- join: bemeurer (~bemeurer@gwnat-wifi-203.sbcc.edu) joined #osdev
14:03:49 --- quit: andrei-n_ (Ping timeout: 240 seconds)
14:13:54 <Brnocrist> "The INT1 instruction also uses a one-byte opcode (F1) and generates a debug exception (#DB) without setting any bits in DR6. The mnemonic ICEBP has also been used for the instruction with opcode F1."
14:17:23 --- quit: light2yellow (Quit: light2yellow)
14:22:10 <radens> Would it be a terrible idea to name your asm functions like mangled c++ names so they include type information and don't need to be extern "C"? Or is the C++ ABI unstable enough that that's a bad idea?
14:24:41 --- quit: bemeurer (Ping timeout: 256 seconds)
14:25:29 --- quit: Amaan (Quit: Connection closed for inactivity)
14:29:31 <lachlan_s> It would be kinda cool to do that to enforce the types passed to a asm routine.
14:30:17 <radens> As long as I have to run all the symbol names through a demangler when I'm debugging anyway, why not?
14:30:33 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:30:42 <radens> But if they compilers do funky shit since there is no stable standard C++ ABI this may not be a great idea.
14:35:23 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
14:48:07 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-lmhqotzdvwrapjim) joined #osdev
14:58:45 --- quit: plonk (Read error: Connection reset by peer)
14:59:14 --- join: plonk (~plonk@rosa.physik-pool.tu-berlin.de) joined #osdev
14:59:14 --- quit: plonk (Changing host)
14:59:14 --- join: plonk (~plonk@unaffiliated/plonk) joined #osdev
15:04:06 --- quit: Asu (Quit: Konversation terminated!)
15:04:19 --- quit: phr3ak (Ping timeout: 264 seconds)
15:06:37 --- quit: opios (Ping timeout: 256 seconds)
15:07:02 --- quit: dennis95 (Quit: Leaving)
15:07:07 --- join: phr3ak (~noreply@gnet.hu) joined #osdev
15:08:39 --- join: opios (~op10s@unaffiliated/opios) joined #osdev
15:08:39 --- quit: opios (Excess Flood)
15:08:43 --- join: hppavilion[0] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
15:08:52 --- join: opios (~op10s@unaffiliated/opios) joined #osdev
15:08:52 --- quit: opios (Excess Flood)
15:09:54 --- join: opios (~op10s@192.69.94.190) joined #osdev
15:09:54 --- quit: opios (Excess Flood)
15:10:46 --- join: opios (~op10s@unaffiliated/opios) joined #osdev
15:10:46 --- quit: opios (Excess Flood)
15:11:16 --- join: opios (~op10s@unaffiliated/opios) joined #osdev
15:11:16 --- quit: opios (Excess Flood)
15:11:28 --- join: opios (~op10s@unaffiliated/opios) joined #osdev
15:11:28 --- quit: opios (Excess Flood)
15:11:56 --- quit: hppavilion[1] (Ping timeout: 260 seconds)
15:15:25 --- quit: hppavilion[0] (Ping timeout: 256 seconds)
15:18:26 --- join: hppavilion[1] (~dosgmowdo@160-7-174-206.gci.net) joined #osdev
15:22:31 <radens> geist: how many bits of ASLR does zircon have for the kernel base? If you're using mcmodel=kernel you can't have more than 19.
15:23:36 --- quit: plonk (Ping timeout: 260 seconds)
15:26:43 --- join: migmatite (~migmatite@2a00:23c4:61a:3600:ec98:1122:3d07:296c) joined #osdev
15:27:22 --- quit: quc (Ping timeout: 265 seconds)
15:31:14 <geist> on x86 maybe, on arm we should have more
15:33:04 <doug16k> radens, where did you get "19" from? just curious
15:34:14 <geist> probablky 47 bits of address space at some granularity
15:34:18 <radens> doug16k: well the top 33 bits are 1 with mcmodel=kernel, so 64-(33+12) is 19
15:34:36 --- quit: xenos1984 (Quit: Leaving.)
15:34:44 <geist> ah i think we just compile a straight relocatable kernel
15:34:50 <geist> so no real mcmodel=kernel stuff
15:35:04 <doug16k> geist, large memory model?
15:35:09 <geist> i forget
15:35:18 --- quit: mawk (Quit: ZNC - https://znc.in)
15:35:20 <radens> there are no mentions of mcmodel=large in the codebase
15:35:22 <geist> also note that arm64 has none of these limitations
15:35:25 <radens> a couple of mcmodel=kernel
15:35:31 <radens> yeah
15:35:36 <doug16k> ah, probably relies on PIC then
15:35:40 <geist> yes. it's PIC
15:36:24 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
15:36:27 <doug16k> geist, arm can represent a 64 bit offset in an addressing mode?
15:36:38 <geist> up to 4GB of offset
15:36:46 <doug16k> so same limitation :)
15:36:51 <geist> so you can run whever you want as long as all of .text/data/bss is within the same 4GB
15:37:06 <doug16k> (as x86)
15:37:08 <radens> geist: are you sure? I mean, you know best but grepping for fpic only shows up USER_COMPILEFLAFS and in third_party/
15:37:25 <geist> actually i dont know best. i haven't implemented any of that
15:37:34 <geist> i have toolchain folks and whatnot to worry about that shit now
15:37:39 <geist> and that's great, because they're really sharp on it
15:38:06 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:38:09 <geist> build with V=1 and you can see the full command line
15:38:36 <radens> geist: the awk script you guys have is a realy head scratcher
15:38:40 <doug16k> radens, was your grep case insensitive?
15:38:45 <radens> doug16k: yup
15:38:57 <radens> I actually used ag but that's just trivia
15:39:20 <geist> ah it's because its -fPIE
15:39:26 <geist> see kernel/arch/x86/rules.mk
15:39:34 <radens> oh thats it
15:40:07 <geist> amd we only use mcmodel=kernel for clang, for another purpose
15:41:18 <radens> huh
15:41:41 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
15:41:56 --- quit: Tazmain (Quit: Leaving)
15:45:37 <doug16k> I just made my kernel use -fPIE instead of -mcmodel=kernel -fno-pic. amazingly, it builds and works
15:45:44 <doug16k> I was 99% sure it wouldn't work
15:46:03 <geist> yeah i dont completely understand why that path works, but i guess -fPIE implies a bunch about the code model it uses
15:46:21 <geist> note that it may not have actually generated as efficient of code
15:46:43 <doug16k> yeah, I'm going to diff it and see if it is using a lot more movabs and stuff
15:47:23 <radens> can you get more bits of ASLR that way?
15:47:37 --- join: mawk (mawk@znc.serveur.io) joined #osdev
15:47:55 <geist> i think so? certainly on arm you can basically align it to 4K boundary anywhere in 48 bits of kernel space
15:48:07 <geist> though i'm going to force a 64k alignment for medium page size
15:50:42 --- quit: baschdel (Ping timeout: 256 seconds)
15:50:45 <geist> note yo still have to actually fix up things to be relocatable. vtables in particular have no solution
15:51:07 --- join: manwar (~manwar@41.37.109.143) joined #osdev
15:51:07 <geist> since the C++ abi (or somewhere) says they'll have the absolute function pointer
15:52:07 --- quit: divine_ (Quit: leaving)
15:52:23 --- join: divine (~divine@2001:470:8247:1::31) joined #osdev
15:53:24 <radens> I was thinking of doing ASLR by just emitting a table of relocations separate from the elf file (because qemu sometimes screws that up) and then just walking through that and replacing the relocations with my new address.
15:53:39 <geist> yep, that's precisely what we do with the confusing awk script
15:53:52 <radens> I'm not entirely sure how to add the table in once it's an exe though.
15:53:53 <geist> basically it generates a table of fixups that gets appended to the kernel that the first cpur uns through on boot
15:54:18 <geist> we just link it twice. we link the kernel and then take that as a payload and wrap it with another binary that has the table emitted at the end
15:54:21 --- quit: migmatite (Quit: migmatite)
15:54:39 <doug16k> it generates 4 more movabs on -fPIE than -mcmodel=kernel
15:54:43 <doug16k> on my kernel
15:54:52 <radens> huh that's not bad.
15:55:01 <geist> oh that's not too bad. with x86-64 its fairly PIC already, wayyy better than it used to be on x86-32
15:55:02 <doug16k> not bad at all
15:55:08 <radens> ah so there's a little bootloader guy which parses the table and does the relocation?
15:55:10 <geist> which is i think where a lot of the hate for PIC came from
15:55:41 <geist> radens: no actually. start.S in the kernel sets the cpu state, branches to the code that was appened to it (at __data_end), which fixes up the kernel, then branches back and continues running
15:55:49 <geist> bss will then pave over the fixup code
15:56:01 <radens> oh that's weird.
15:56:20 <geist> i think it's basically what linux does, as someone told me
15:56:21 <doug16k> let me compare lea to be sure
15:56:52 <radens> geist: is the code which was appended in image.S?
15:56:58 <geist> yes
15:57:08 <radens> now it all makes sense.
15:57:19 <geist> it adds a little header to the start for other reasons, and then that fixup routine is what start.S branches to (it ends up at __data_end)
15:57:31 <geist> and that is just a blatted out table of generated code
15:57:50 <geist> if you build it and look at that fixups.inc you can see what it's mostly fixing up
15:57:57 <geist> and they're all REL_ABS64s basically
15:58:07 <doug16k> -mcmodel=kernel: 3154 lea instructions, -fPIE: 5005 lea instructions
15:58:09 <geist> and pretty much almost always in the .data and .rodata section
15:58:25 <doug16k> so yeah, there is some overhead, but not terrible
15:59:08 <geist> yah
15:59:18 <geist> even that it's sort of debatable in many cases if that's any slower
15:59:32 <geist> because it uses more leas doesn't mean it wasn't just replacing one thing with someone else that is about the same
15:59:42 <geist> in some cases its probably additional code, but not necessarily always
16:00:02 <geist> though i can't think of any particular examples
16:00:07 <doug16k> yeah, it is only likely to affect accesses to global variables with an array index. not something you do all that much
16:00:27 <aalm> ywp
16:00:27 <radens> maybe your GDT?
16:00:52 <doug16k> it would have to lea the base of the array then SIB with the register. in mcmodel=kernel it could use an offset as the base
16:01:15 <doug16k> radens, yeah, and that is accessed approximately zero times :D
16:01:34 <doug16k> explicitly I mean
16:01:51 <geist> i just spent the last week debugging that relocation table stuff, and just debugged it to
16:02:05 <geist> https://fuchsia-review.googlesource.com/c/zircon/+/153211/1/kernel/arch/arm64/start.S#68
16:02:05 <bslsk05> ​fuchsia-review.googlesource.com <no title>
16:02:18 <geist> you can imagine what happens if every secondary cpu bootstrap *also* repatches the kernel
16:02:28 <geist> surprisingly that was only rarely fatal
16:02:36 <doug16k> :O
16:02:48 <geist> for reasons that we worked out (right now we're only offsetting 0, so it was mostly just loading/adding 0/storing
16:02:59 <geist> so it has to be a really tight race, but it is as all the secondary cores come on line
16:04:14 --- quit: manwar (Quit: leaving)
16:05:08 <radens> geist: move_fixups_and_zero_bss is kind of gnarly.
16:05:26 <doug16k> geist, you only have to handle one relocation type to randomize the kernel base?
16:05:39 <geist> doug16k: yes, though we also made special care of that
16:05:55 <geist> specifically we needed to compile with -fPIE and then make sure all of our asm was also PIE
16:06:06 <geist> but the gist is it ends up with the only type of relocations being ABS64
16:06:08 <doug16k> ah
16:06:14 <doug16k> neat
16:06:30 <geist> if we had loadable ekrnel modules that might make things more complex, though
16:06:45 <radens> Yeah I've got those.
16:06:50 <geist> but as it stands it's a single standalone image, so the only kind of relocations are within the kernel, and the only ones that matter are the ones with hard addresses stored
16:07:01 <doug16k> I have those. I wonder if fPIE broke them
16:07:05 --- join: Arcaelyx (~Arcaelyx@2604:2000:f14a:2500:e887:f2b0:4dbe:37bd) joined #osdev
16:07:18 <radens> Admittely I'm not using many right now, so maybe I should just ditch them? But I kind of like them.
16:07:25 <geist> probably not, as long as the kernel tiself doesn't have any external references
16:07:29 <geist> but the other way may be difficult
16:08:10 <radens> Nah my kernel module is working with -fPIE.
16:08:55 <doug16k> I'm pessimistic because I remember early on PIC causing me problems. maybe my link was not right or it was weirdness from using the system linker (I use cross compiler now)
16:10:07 <doug16k> I was also basing my kernel at 0xffff800000000000, which I know now was a terrible idea :)
16:10:56 <geist> may also be the subtle difference between -fPIC and -fPIE
16:11:09 <geist> also, x86-64 and arm64 are particularly easy to relocate
16:11:10 <doug16k> yeah, that could be it too. it was PIC
16:11:16 <geist> if you tried the same thing with x86-32 you may not go to space
16:15:54 --- join: plonk (~plonk@rosa.physik-pool.tu-berlin.de) joined #osdev
16:15:54 --- quit: plonk (Changing host)
16:15:54 --- join: plonk (~plonk@unaffiliated/plonk) joined #osdev
16:17:41 <radens> okay, so I'm messing around with the -fPIE and stuff, and the last step I do is copy my elf file from a 64 bit elf file to a 32 bit one since qemu won't boot 64 bit elf files. But when I do that with a -fPIE kernel objcopy chokes
16:21:04 --- join: ryoshu (~kamil@netbsd/developer/kamil) joined #osdev
16:21:05 <ryoshu> hi
16:21:24 <ryoshu> how to switch in a program from 64-bit to 32-bit mode (x86)?
16:21:46 <ryoshu> I have a code that is doing it,but I don't fully understand all the nits in it
16:23:05 <geist> in what context?
16:23:24 <geist> as in a program on top of an OS, or a piece of bare metal code running directly on the cpu?
16:23:37 <ryoshu> a program on NetBSD/amd64
16:23:48 <geist> fairly certain you can't
16:23:49 --- join: zmzm (~zmzm@gateway/tor-sasl/zmzm) joined #osdev
16:24:05 <geist> i dont know of any OS in particular that lets you sswitch the operating mode of a process from 64 to 32
16:24:15 <ryoshu> http://paste.asie.pl/CIUn
16:24:16 <bslsk05> ​paste.asie.pl <no title>
16:24:28 <geist> since to generally do it you need to fiddle with GDT/LDT and you can't do that in user space
16:24:33 <ryoshu> this works.. but I'm trying to understand what is this CS selector
16:25:01 <geist> ah, well then i guess that does work
16:25:07 <ryoshu> it works
16:25:11 <Mutabah> Presumably that's the 32-bit code segment for netbsd
16:25:13 <geist> yah
16:25:29 <geist> actually i guess if the OS does have a 32bit code selector, then i guess that should pretty much always work
16:25:37 <ryoshu> Mutabah please elaborate, it's unclear for me :)
16:25:44 <geist> as long as it's in the GDT and visible. never occurred to me that it would
16:26:18 <ryoshu> what is this 32bitcode selector?
16:26:27 --- quit: magnificrab (Ping timeout: 240 seconds)
16:26:55 <ryoshu> something predefined in the kernel?
16:27:02 <ryoshu> in compat32 mode?
16:28:30 <geist> it's pretty complicated, is probably no one wants to describe it
16:28:51 <geist> i'm not entirely sure where to begin, since it requires an understanding of x86's overly complicated segmentation scheme
16:28:58 <geist> but yes. basically it's something predefined in the kernel
16:29:15 <ryoshu> what to grep for?
16:29:27 <geist> not a clue
16:29:38 <geist> gdt maybe?
16:29:50 <geist> it'll be an entry in netbsd's gdt
16:30:05 <geist> if i weren't busy right now trying to get a commit in before end of day i'd help ya but ic an't right now
16:30:06 <ryoshu> Next question.. is this .word 0x73 used at all?
16:30:08 <ryoshu> by cpu?
16:30:12 <ryoshu> I think it's not used
16:30:24 <ryoshu> but maybe there is a special case when switching mode?
16:30:58 <geist> it is
16:31:13 <geist> that number is absolutely important
16:31:26 <ryoshu> I think we put into rax address of field containing the address of trigger32, far jump there
16:32:01 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
16:34:37 <doug16k> when you ljmp memory indirect (as it is doing) it loads cs:rip from the memory operand, with the first 32 bits being the offset and the following 16 bits being the code segment selector
16:35:12 <doug16k> loading a selector which refers to a compatibility mode code segment essentially switches that thread to 32 bit mode (from the perspective of that thread)
16:35:35 <doug16k> the machine is still in long mode and interrupt handling, etc, will still be 64 bit
16:36:01 <ryoshu> I see
16:36:03 <doug16k> compatibility mode means long mode but instructions are decoded as if it were 32 bit mode
16:36:06 --- quit: mwk (Quit: leaving)
16:36:12 <ryoshu> So I have 2 questions:
16:36:20 --- join: mwk (~mwk@fsf/member/mwk) joined #osdev
16:36:33 <ryoshu> 1. can this code be PIE? I mean RIP-relative addressing
16:36:55 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
16:36:56 <ryoshu> 2. what / where is 0x73, but this is for my grepping abilities, so far I don't see anything with that number
16:37:08 <doug16k> 32 bit code can be PIE, but it can't use rip-relative addressing mode, it would probably use %ebx
16:37:17 <variable> o.O o.O
16:37:44 * variable wonders how doug16k knows anything about 32 bit code
16:37:45 <ryoshu> context: I want to compile this assembly into a program that is compiled with -pie
16:37:59 <variable> doug -> 16 <- k
16:38:01 <doug16k> variable, what?
16:38:05 <doug16k> I'm 41
16:38:18 <variable> doug16k: your name
16:38:22 <ryoshu> I don't want to change compiler options for the whole program for this single function
16:38:42 <doug16k> yeah, just some crap I tacked onto my name so I don't have a different username everywhere :D
16:38:50 <variable> :(
16:38:54 <ryoshu> doug16k I mean, can I switch to 32bit compat mode with PIE? I think I can try to set dynamically .long trigger32
16:38:58 <olsner> variable: use more than 14 address bits and it's just the same 16k repeating
16:38:59 <variable> doug16k: I was trying to make a joke; I failed; :(
16:39:17 <doug16k> oh I thought you noticed an error and were being snarky :D
16:39:23 <geist> you failing at jokes is a constant
16:40:02 <ryoshu> variable hi
16:40:19 --- quit: freakazoid0223 (Ping timeout: 240 seconds)
16:41:37 <doug16k> ryoshu, you'll need to look at the 32 bit x86 ELF ABI spec to see how you need to initialize ebx for entry into 32 bit code
16:41:51 <doug16k> assuming that code is compiled PIC
16:42:37 <variable> geist: :(
16:42:39 <doug16k> also assuming you need ELF ABI (probably do)
16:42:47 <geist> variable: that was a joke too
16:42:59 <variable> geist: ::)
16:43:13 * variable has four eyes
16:43:26 <variable> okay, I'll try to be helpful for real
16:43:44 <ryoshu> doug16k ok, first I'm looking at this cs selector, trying to find where is that in the kernel
16:44:01 <doug16k> ryoshu, look for the place that sets up the GDT
16:44:35 <doug16k> 0x73 should be the 14th one
16:44:44 <doug16k> s/one/descriptor/
16:45:01 <ryoshu> why 14th? looking
16:45:10 <doug16k> 0x73 >> 3 is 14 (decimal)
16:45:20 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
16:45:31 <ryoshu> I think I got it
16:45:38 <doug16k> bit 2 selects GDT or LDT (0=GDT, 1=LDT), bit 1:0 select RPL (requested privilege level)
16:45:46 <doug16k> 3=user mode
16:46:24 <ryoshu> it makes sense
16:48:36 <ryoshu> https://nxr.netbsd.org/xref/src/sys/arch/amd64/amd64/machdep.c#1755
16:48:39 <bslsk05> ​nxr.netbsd.org: Cross Reference: /src/sys/arch/amd64/amd64/machdep.c
16:49:27 --- quit: Kimundi__ (Ping timeout: 255 seconds)
16:52:47 <ryoshu> GUCODE32_SEL = 14
16:53:24 --- quit: Guest22823 (Ping timeout: 250 seconds)
16:53:38 <ryoshu> doug16k thank you very much!
16:53:57 <ryoshu> I will try now to figure out this PIE-compatible code and be done :)
16:55:03 --- quit: lachlan_s (Quit: Connection closed for inactivity)
16:55:57 --- join: mawk` (sabu@znc.serveur.io) joined #osdev
16:56:26 --- quit: mawk (Ping timeout: 250 seconds)
16:57:07 --- nick: mawk` -> mawk
16:57:51 --- quit: EvanCarroll (Remote host closed the connection)
16:58:47 <doug16k> ryoshu, :)
17:00:38 --- quit: sortie (Quit: Leaving)
17:01:30 --- join: isd (~isd@pool-71-174-32-198.bstnma.east.verizon.net) joined #osdev
17:02:23 --- quit: vmlinuz (Quit: Leaving)
17:02:35 --- quit: zmzm (Quit: zmzm)
17:05:51 --- join: zmzm (~zmzm@gateway/tor-sasl/zmzm) joined #osdev
17:12:41 --- quit: magnificrab (Ping timeout: 260 seconds)
17:14:58 --- join: bemeurer (~bemeurer@2600:8802:5300:bb90:863a:4bff:fe06:c8b2) joined #osdev
17:17:40 --- quit: zesterer (Ping timeout: 268 seconds)
17:23:25 --- quit: stee (Remote host closed the connection)
17:23:45 --- join: stee (~junk@66.252.139.92) joined #osdev
17:24:11 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
17:26:49 --- quit: awang_ (Ping timeout: 240 seconds)
17:37:26 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
17:48:26 --- nick: promach__ -> promach2
17:48:36 --- join: dbittman_ (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
17:49:07 --- join: ACE_Recliner (~ACE_Recli@c-73-18-225-48.hsd1.mi.comcast.net) joined #osdev
17:58:49 --- join: vaibhav (~vnagare@125.16.97.112) joined #osdev
18:00:25 <radens> How concerned should I be about mapping all of memory at some offset in the virtual address space? It seems like an awfully big security hole.
18:07:47 --- quit: adam4813 (Quit: Connection closed for inactivity)
18:08:06 --- quit: bork (Ping timeout: 260 seconds)
18:10:24 --- join: bork (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
18:13:47 --- quit: promach2 (Remote host closed the connection)
18:17:48 --- quit: zmzm (Quit: zmzm)
18:18:52 --- quit: tacco| ()
18:19:44 --- join: climjark_ (~climjark@c-24-0-220-123.hsd1.nj.comcast.net) joined #osdev
18:20:19 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-bpuyfxbmzmqgrckw) joined #osdev
18:20:24 <climjark_> hello all
18:21:15 <climjark_> im still trying to figure out the best way to deal with memory management, i finally got my paging setup correctly (for the most part i guess?)
18:22:04 <_mjg_> congrats
18:25:36 <climjark_> thanks , im grabbing GRUBs memory map, i should probably place the memory structure around the available memory right? also does it display virtual addresses or physical?
18:27:03 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
18:27:34 <radens> physical. Grub doesn't have paging enabled.
18:27:40 <climjark_> true
18:28:50 <Mutabah> radens: Not the best idea really
18:29:00 <Mutabah> radens: There's more physical memory than there is virtual memory
18:29:19 <Mutabah> Weeelll. more space anyway
18:29:19 <radens> Mutabah: huh?
18:30:01 <radens> I mean I'll be mapping device memory as normal memory, which is bad, but I won't have problems if I don't touch it.
18:31:42 <radens> Mutabah: Do you recommend creating a special pool of physical pages which can be used for making page tables? Or is there a more elegant way for constructing page tables?
18:32:09 --- nick: promach__ -> promach2
18:32:35 <Mutabah> Just the general pool?
18:33:11 <radens> Mutabah: but how do I get a virtual address for those pages so I can write to them?
18:43:27 <Mutabah> Well... I use fractal mapping
18:43:52 <Mutabah> but you can have a single page always mapped in that you can manipulate
18:44:06 <Mutabah> (a single PT mapped as both a PT and as a data page)
18:45:47 <ryoshu> hi
18:46:23 --- quit: divine (Read error: No route to host)
18:46:42 <climjark_> hello ryoshu
18:47:14 <ryoshu> http://paste.asie.pl/fvSh assembly inline question.. why 'Error: operand type mismatch for `lea'' ?
18:47:14 <bslsk05> ​paste.asie.pl <no title>
18:48:03 <ryoshu> long rip;
18:48:49 --- quit: JusticeEX (Quit: Lost terminal)
18:48:56 <Mutabah> ryoshu: lea takes a memory operand
18:49:09 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
18:49:40 <ryoshu> I want to put into %rax, address of 'rip' variable
18:50:41 --- quit: variable (Quit: /dev/null is full)
18:52:50 <ryoshu> hm, I've tried movq and : "r"(&rip).. checking it out
18:54:01 <ryoshu> it builds, thanks :)
18:56:41 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
18:58:19 --- quit: isd (Ping timeout: 240 seconds)
18:59:44 --- join: NaNkeen (~nankeen@115.164.80.206) joined #osdev
19:02:09 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:04:05 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
19:07:11 --- join: MarchHare (~Starwulf@mo-184-5-204-232.dhcp.embarqhsd.net) joined #osdev
19:13:42 --- join: opios (~op10s@192.69.94.190) joined #osdev
19:13:42 --- quit: opios (Changing host)
19:13:42 --- join: opios (~op10s@unaffiliated/opios) joined #osdev
19:16:42 <radens> Mutabah: that seems like an inelegant solution
19:16:52 <radens> granted I haven't yet found an elegant one.
19:27:13 --- join: SGautam (~GautamS@unaffiliated/gautams) joined #osdev
19:27:55 --- quit: SGautam (Max SendQ exceeded)
19:28:36 --- join: SGautam (~GautamS@unaffiliated/gautams) joined #osdev
19:29:09 --- quit: SGautam (Max SendQ exceeded)
19:29:41 --- join: SGautam (~GautamS@unaffiliated/gautams) joined #osdev
19:30:28 --- quit: SGautam (Max SendQ exceeded)
19:30:59 --- join: SGautam (~GautamS@unaffiliated/gautams) joined #osdev
19:31:05 --- quit: SGautam (Max SendQ exceeded)
19:39:26 --- join: mrush (~user@unaffiliated/mrush) joined #osdev
19:39:42 --- join: awang_ (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
19:46:10 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
19:55:07 <ryoshu> http://paste.asie.pl/AOJ4
19:55:07 <bslsk05> ​paste.asie.pl <no title>
19:56:04 <ryoshu> http://paste.asie.pl/2AIx <- generated code, what's wrong with this inline syntax?
19:56:04 <bslsk05> ​paste.asie.pl <no title>
19:56:28 <ryoshu> instead of using pointers/variables, it's using %rax and generates trash code
19:56:33 <ryoshu> pointers*
19:59:37 <ryoshu> %0 and %1 are replaced with.. %rax instead of using variables
20:03:42 <ryoshu> ah, got it
20:03:45 <ryoshu> "a" -> rax
20:14:19 --- quit: nj0rd (Ping timeout: 256 seconds)
20:16:12 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
20:16:42 --- quit: stee (Quit: stee)
20:23:09 <geist> yep
20:23:20 <ryoshu> "m" works
20:25:03 --- quit: lachlan_s (Quit: Connection closed for inactivity)
20:28:59 --- join: nj0rd (~nj0rd@i577BC033.versanet.de) joined #osdev
20:31:15 --- quit: masoudd (Quit: May your strings always be '\0' terminated.)
20:34:45 --- join: quc (~quc@host-89-230-168-176.dynamic.mm.pl) joined #osdev
20:48:04 <variable> don't you love when debugging, and gdb decides to crash
20:48:16 <ryoshu> hi variable
20:48:21 <variable> hi ryoshu
20:49:19 <ryoshu> I'm writing a regression tests for the NetBSD kernel to check whether CVS-2018-2297 is mitigated.. and I think I'm done.. I will need to boot old kernel to check for sure
20:50:01 <ryoshu> variable where are you using gdb, what OS?
20:59:55 --- join: oaken-source (~oaken-sou@194.152.148.167) joined #osdev
21:01:50 --- join: EvanCarroll (~ecarroll@172.56.14.148) joined #osdev
21:05:58 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
21:08:15 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:14:13 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
21:14:15 --- quit: AverageJ0e (Ping timeout: 250 seconds)
21:14:48 --- join: stee (~junk@66.252.139.92) joined #osdev
21:19:24 --- quit: NaNkeen (Ping timeout: 268 seconds)
21:21:46 --- quit: stee (Ping timeout: 260 seconds)
21:23:54 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
21:24:07 --- quit: hppavilion[1] (Ping timeout: 264 seconds)
21:31:05 --- join: stee (~junk@66.252.139.92) joined #osdev
21:34:49 --- quit: quc (Remote host closed the connection)
21:35:06 --- join: quc (~quc@host-89-230-168-176.dynamic.mm.pl) joined #osdev
21:52:55 <variable> ryoshu: FreeBSD - kgdb, get an internal assertion error. I got deep into gdb code and now I think I need to go learn more about ELF to properly understand what's going on
21:53:19 <ryoshu> I see
21:53:42 <ryoshu> my PIE code doesn't work... I will resume it tomorrow, goodnight
21:54:00 <variable> ryoshu: https://reviews.freebsd.org/P176
21:54:01 <bslsk05> ​reviews.freebsd.org: ✎ P176 gdb crashing with dumptid = 0
21:59:49 --- quit: quc (Remote host closed the connection)
22:00:06 --- join: quc (~quc@host-89-230-168-176.dynamic.mm.pl) joined #osdev
22:13:15 --- quit: Arcaelyx (Max SendQ exceeded)
22:19:23 --- join: Arcaelyx (~Arcaelyx@2604:2000:f14a:2500:e887:f2b0:4dbe:37bd) joined #osdev
22:25:04 --- quit: drakonis (Remote host closed the connection)
22:30:01 --- quit: zeus1 (Ping timeout: 260 seconds)
22:41:18 --- join: KernelBloomer (~SASLExter@gateway/tor-sasl/kernelbloomer) joined #osdev
23:02:18 --- quit: pounce (Quit: WeeChat 2.1)
23:03:38 --- quit: Lucretia (Ping timeout: 256 seconds)
23:09:02 --- join: Tegu (kekkont1@gateway/shell/tkk.fi/x-radfmilrwzwrtutt) joined #osdev
23:09:09 --- quit: latentprion (Ping timeout: 256 seconds)
23:11:04 --- join: latentprion (~latentpri@2402:1800:4000:1:6600:6aff:fe94:3eb7) joined #osdev
23:11:53 <bauen1> oh boy, I was so sleepy I was unable to copy+paste some simple code yesterday -.-
23:13:23 --- quit: szpght_ (Ping timeout: 256 seconds)
23:13:29 --- quit: Olgierd (Ping timeout: 268 seconds)
23:14:01 --- join: Amaan (uid4967@gateway/web/irccloud.com/x-wymkddpddgexgbwk) joined #osdev
23:14:57 --- join: Mistell (~james@unaffiliated/magejames) joined #osdev
23:16:53 --- quit: Mistell (Quit: WeeChat 2.1)
23:23:19 --- quit: climjark_ (Ping timeout: 240 seconds)
23:26:10 --- quit: promach2 (Remote host closed the connection)
23:26:31 --- join: SGautam (~GautamS@unaffiliated/gautams) joined #osdev
23:28:13 --- join: andrei-n_ (~andrei@51.214-65-87.adsl-dyn.isp.belgacom.be) joined #osdev
23:28:18 --- quit: Goplat (Remote host closed the connection)
23:30:23 --- quit: EvanCarroll (Ping timeout: 256 seconds)
23:31:15 --- quit: Kazinsal (Read error: Connection reset by peer)
23:31:41 --- join: Kazinsal (~Kazinsal@unaffiliated/kazinsal) joined #osdev
23:32:12 --- quit: dbittman_ (Ping timeout: 255 seconds)
23:37:07 --- join: alexneudatchin (~alexn___r@31.148.138.118) joined #osdev
23:39:36 --- quit: alexneudatchin (Quit: Leaving)
23:48:16 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
23:53:59 --- quit: andrei-n_ (Quit: Leaving)
23:54:30 --- join: xerpi (~xerpi@253.red-83-45-194.dynamicip.rima-tde.net) joined #osdev
23:55:11 --- quit: SGautam (Ping timeout: 260 seconds)
23:57:49 --- join: m_t (~m_t@p5DDA3319.dip0.t-ipconnect.de) joined #osdev
23:59:59 --- log: ended osdev/18.05.11