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=19&m=5&d=12
12:01:09 <adu> https://youtu.be/iffTJ1vPCSo
12:05:01 <adu> zid: I would start with https://github.com/corna/me_cleaner (has a minimal ME), then somehow add your own stuff?
12:06:02 <adu> well, no, I would start with qemu-sparc, then move onto that
12:08:45 <adu> zid: also, why did your bios not support your cpu?
12:09:00 <doug16k> alberinfo_osdev, just being there in info tab isn't enough. cpu has to be in correct permission and page permissions must allow the access
12:09:41 <alberinfo_osdev> supervisor level and read/write for paging
12:09:55 <doug16k> info sreg tells you cpl?
12:10:07 <doug16k> it's cs dpl
12:15:45 <alberinfo_osdev> says es, ds, fs, gs, ss: 0x10, dh=9300, dl=FFFF, valid=1, base 0, limit 0xFFFF, read/write, accessed and cs: 0x08, dh=209B00, dl=FFFF, valid = 1, base 0, limit FFFF, excecute/read, non-conforming, accessed 64-bit.
12:24:56 <doug16k> ok definitely ring 0
12:28:25 <alberinfo_osdev> yes
12:51:12 <doug16k> alberinfo_osdev, was something previously mapped at that location?
12:51:21 <doug16k> at that virtual address
12:53:03 <doug16k> when you switch to long mode, you should toggle CR4.PGE to 1 (then back to 0 if you don't use global pages)
12:53:16 <doug16k> that will fully flush the tlb
12:54:07 <doug16k> if you are certain that the page tables have that mapped correctly, then it must be stale mapping
12:54:21 <doug16k> you have interrupt handlers? it is definitely a page fault?
12:56:47 <alberinfo_osdev> i dont have anythingmapped to that address. i dont have any interrupt handler, but it's definitly a page fault, see that cr2 is set. ill try enabling global pages, and then in 64-bit disabling it
12:59:27 <alberinfo_osdev> still not working when flushing tlb with enabling and disabling CR4.PGE
01:07:21 <doug16k> you have that physical memory mapped though right?
01:07:31 <doug16k> all memory accesses require page tables for the region
01:07:39 <bcos> adu: If you want to do some firmware work; could you *please* implement (port?) some UEFI firmware to Bochs for me? :-)
01:07:57 <alberinfo_osdev> if you mean to C000066A, no.
01:08:00 <adu> bcos: ok
01:08:18 * bcos wasn't expecting that..
01:08:23 <doug16k> alberinfo_osdev, well that's your problem. you have to set up page tables for all memory regions you wish to access
01:08:24 * bcos does the happy dance!
01:08:25 <bcos> :-)
01:09:02 <adu> bcos: what isa?
01:09:11 <adu> never used bochs before
01:09:14 <alberinfo_osdev> but i dont wish to access 0xC000066A, not even i dont know why its calling that address, since i just want to read the mboot_header
01:09:18 <doug16k> adu, bochs is an x86 emulator
01:09:33 <adu> oh, well, then that should be easier
01:09:49 <adu> sounds like a job for duet
01:09:49 <doug16k> parts of qemu are from bochs actually
01:10:08 <doug16k> qemu deserves credit for making cpu part blazing fast in comparison
01:10:22 <bcos> adu: Ah - would want 64-bit 80x86 UEFI (32-bit 80x86 isn't worth worrying about). Would be able to start with Tianocore's OVFM - it's been ported to Qemu, but there's some kind of difference between Qemu and Bochs that prevent it from working there
01:10:52 <doug16k> bcos, I bet the difference is ACPI being absent
01:11:37 <adu> bcos: have you tried duet?
01:11:42 <bcos> Hrm - might be able to cut&paste the existing ACPI tables from Bochs into the firmware and..
01:11:54 <doug16k> bcos, that would probably go a long way
01:11:56 <bcos> adu: No, not tried duet
01:14:48 <adu> bcos: my theory of how it would work with linux, is an MBR partition table with DUET-BS32 as the VBR of the first partition, which must be formatted FAT, with /Efildr20 and Shell.efi copied to /efi/boot/bootx64.efi, and linux cmdline script at /efi/boot/startup.nsh, and linux kernel at /vmlinuz
01:15:19 <doug16k> the most straightforward way to do it might be to implement the fw_cfg device in bochs and provide the acpi tables to seabios through that mechanism
01:15:42 <adu> I know how to dd, I don't know how to fw_cfg
01:16:25 <doug16k> https://wiki.osdev.org/QEMU_fw_cfg
01:16:45 <doug16k> it's a piece of virtual hardware that lets the guest get blocks of stuff from the host
01:16:53 <adu> doug16k: I thought bcos said bochs
01:17:00 <doug16k> ya
01:17:20 <bcos> adu: I mostly just use "diskless" test machines that boot from CD or network, The DUET stuff looks painful to install/setup (based on https://superuser.com/questions/619226/what-can-tianocores-duet-be-used-for-in-a-pc )
01:17:38 <doug16k> the most straightforward way to get acpi up in bochs would be to implement fw_cfg interface so seabios code already works to get the acpi tables
01:18:09 <doug16k> i.e., make bochs compatible with the way qemu delivers acpi tables to guest
01:18:45 <doug16k> alternative would be to add some #ifdef stuff to seabios and make it get the tables from bochs some new way
01:19:38 <bcos> doug16k: Bochs doesn't really have any reason to care about the host (it's a full system emulator without any pass-through, not a hyper-visor)
01:20:03 <doug16k> the host tells it how many cpus there are, their ids, how much ram, phys mem map, etc etc
01:20:22 <doug16k> in real world he motherboard manufacturer did something
01:21:32 <bcos> Hrm - should be able to auto-detect most of that (e.g. broadcast "INIT, SIPI, SIPI" sequence and figure out CPUs from what got started). Memory detection is just plucking a value from CMOS
01:21:53 <doug16k> e820 comes almost straight from ACPI table. e820 api is part of acpi spec
01:22:01 <bcos> Erm
01:22:27 <bcos> E820 was from Phoenix in the early 1990s (and got adopted by ACPI after)
01:22:59 <doug16k> you know a lot. what I said is still true
01:23:15 <doug16k> it is in the acpi spec
01:23:40 <doug16k> adopted then
01:24:17 <doug16k> go look at qemu, the host builds the tables
01:24:35 <doug16k> injects them using fw_cfg device
01:24:46 <doug16k> seabios probes for it and installs them where they will be found
01:27:55 <bcos> What I mean was; for Bochs, the "amount of memory" parameter from the "bochsrc.txt" file gets shoved into a CMOS location and the firmware just plucks that out and uses it as the basis for all its memory management
01:28:01 <doug16k> you could set up some totally hardcoded tables though to see how far that gets you
01:28:11 <doug16k> if that works then worry about the info being accurate
01:28:27 <doug16k> what else would prevent OVMF working?
01:28:41 <doug16k> hopefully has IDE driver
01:29:12 <doug16k> I think it does
01:29:34 <bcos> I couldn't say what prevents OVMG from working on Bochs - could be chipset differences, different devices, different ACPI, different support for SMM, ...
01:29:41 <bcos> *OVMF
01:30:31 <doug16k> ovmf works without -q35? they'd both be piix right?
01:30:54 <doug16k> so it would be promising
01:31:16 <bcos> Bochs is "PIIIX with artificial fake extensions for everything that never existed in the original PIIIX"
01:31:21 <adu> crap
01:31:28 <doug16k> what is it? 82371SB or something?
01:31:32 <adu> I meant to press F12 and I pressed poweroff
01:31:45 <doug16k> or 82731SB?
01:32:02 <adu> o wait n/m it was hybernate
01:33:20 <bcos> (for "chonologogy" it's a bizarre franken-beast - an old 1990s chipset with a modern 64-bit CPUs, APICs, HPET, etc)
01:33:40 <bcos> (there's even strange quirks for things like device ROMs, where PCI devices have ISA ROMs)
01:33:50 <bcos> (..and no BARs in the device's PCI config space)
01:34:21 <bcos> *chronology
01:34:41 <bcos> (assuming it hasn't changed since I last diddled that fiddle)
01:36:46 <doug16k> has anyone actually tried that abomination of a build system in ovmf?
01:36:51 <adu> hmm
01:36:57 <adu> bochs doesn't like alpine
01:36:58 <doug16k> I took one look at it and said forget it
01:37:46 <adu> I wonder if it's the long mode transition
01:37:58 <doug16k> my 64 bit kernel works in bochs
01:38:43 <doug16k> i.e. bochs is probably doing that part right
01:38:43 <adu> ok, the logs say something like
01:39:00 <adu> int 15h function AX=ec00, BX=0002 not yet supported
01:39:09 <adu> KBD: unsupported 16h function 03
01:40:49 <doug16k> both look pretty harmless
01:41:30 <adu> oh it also says CPU is in protected mode (halted)
01:42:07 <doug16k> anything about exception or interrupt right beore that?
01:42:36 <alberinfo_osdev> goodbye guys
01:42:47 <doug16k> alberinfo_osdev, bye
01:43:02 <adu> let me ssh
01:43:11 <adu> I'm currently switching between a macbox and linuxbox
01:43:26 <adu> by moving my hands 1 foot between kbds
01:44:09 <bcos> adu: What is "int 15h function AX=ec00, BX=0002" (is the the "inform firmware I plan to use 64-bit" thing AMD made the mistake of inventing)?
01:46:03 <bcos> Ah - it is. OS needs to assume that function might not exist
01:46:12 <adu> "Physical KASLR disabled: no suitable memory region!"
01:46:24 <zid> my ipv6 died, I tried to reconnect to efnet/freenode on ipv4, and apparently I am on the efnet blacklist O_o
01:46:32 <adu> "[88.228504] Initramfs unpacking failed: write error"
01:48:25 <doug16k> adu, it is probably running too slow
01:48:59 <zid> irc has exploded
01:49:09 <doug16k> increase IPS might help with that
01:49:16 <remexre> zid: yeah, same here, and for the guy sitting next to me
01:49:21 <doug16k> less wallclock time will elapse from guest perspective
01:49:27 <zid> remexre: Which bits are the same?
01:49:57 <remexre> zid: getting booted from IRC just now
01:49:58 <adu> https://ghostbin.com/paste/69b5a
01:50:09 <zid> my ipv6 went down, that's why I got booted
01:50:30 <remexre> zid: huh, nvm then
01:50:47 <zid> "For further information, please contact an EFnet spamtrap administrator." okay, how? :P
01:50:52 <doug16k> linux (is so big and slow that it) will timeout bochs during boot if you don't set IPS high enough
01:51:32 <doug16k> it is not pretty early on
01:52:41 <doug16k> linux is pretty sure it can't take that long so it errors out when it was working okay
01:52:59 <bcos> Watchdog built into Linux?
01:53:10 <doug16k> several things timeout during boot ya
01:53:20 <doug16k> if the computer is extraordinarily slow
01:53:37 <doug16k> user level stuff. not a hard panic thing
01:55:18 <doug16k> "write error" could be as silly as a program timing out and exiting ungracefully, then something errors writing to a pipe
01:55:37 <adu> bcos: no, iirc it's CR4.PAE
01:57:50 <bcos> adu: I can't find context (what is "it")?
01:58:07 <adu> it is the "thing AMD made the mistake of inventing"
01:58:28 <bcos> Intel invented PAE
01:59:00 <adu> but I thought AMD invented 64-bit long mode
01:59:12 <doug16k> PAE predates long mode
01:59:31 <zid> extended page table bits != full 64bit isa :P
02:00:10 <bcos> "int 15h function AX=ec00, BX=0002" was invented by AMD with the idea that firmware could "optimise unknown stuff" (e.g. SMM code?) based on what the first OS said it might use (if OS says it won't use 64-bit, or might use it, or will use it). It was a silly idea because 123 different things could happen before and after OS boots (e.g. "kexec()")
02:02:00 * bcos mostly learnt to hate that BIOS function because the boot code for the previous version of his OS would gather info, discard the BIOS, then gather more info, then decide whether to start a 32-bit kernel or 64-bit kernel - too late to inform BIOS of anything
02:02:48 <bcos> ..and (if I remember right) if you tell the BIOS "might use 64-bit" then it can just return a "not supported" error and ...
02:03:19 <doug16k> hypothetically though? or really?
02:03:38 <bcos> Who knows!
02:04:14 <doug16k> would be sad if the firmware locks up the machine because it didn't give some hint call that someone dreamed up yesterday
02:04:39 <bcos> I remember ages ago (not long after it first came out? Probably 10+ years ago) a few us tried to figure out what the BIOS function actually did, and started reverse engineering it on a real computer to find that it reset half the stuff on the chipset and ruined/corrupted anything a boot loader might have done before calling it
02:06:19 <doug16k> sounds like you definitely need a chicken bit to disable calling that if your implementation can call it
02:08:00 <bcos> Just call it and ignore errors if it's not supported
02:08:22 <bcos> - doesn't seem to matter on modern hardware at a least
02:09:29 <bcos> (I suspect that originally firmware developers didn't know what it was supposed to do and used "shotgun logic" to cover random possibilities, but since then have realised it's stupid and probably changed it so it doesn't actually do anything)
02:10:03 <bcos> (although I also suspect Intel didn't bother to start with - hard to be sure though)
02:11:58 <adu> bcos: that sounds like a justification for the existance of both uefi and multiboot
02:13:10 <adu> if I were to design UEFI from scratch, it would have forward slashes and use ELF, not PE
02:13:17 <bcos> "while(time_passes) { baggage_accumulates(); }" - anything "new" seems nice and clean until it gets older
02:15:05 <bcos> For the design of UEFI, historical context is needed - Intel were desperately trying to stick their tongue in Microsoft's butt in the hope of getting Microsoft to support Itanium, so...
02:15:23 <adu> I think coreboot it important because it has the potential of removing all of the cargo cult programming in the bios
02:16:31 <bcos> Well, no. Coreboot on its own doesn't work - you need a payload, and that payload is "all of the cargo cult programming in the BIOS" (I think they just ported SeaBIOS)
02:16:48 <zid> There's honestly nothing wrong with bios stuff imo
02:17:19 <zid> secureboot is trivially bypassable, and it's honestly *more* work to be uefi compatible than just have the bios boot you and write that code instead
02:17:24 <adu> zid: intel-me is technically bios
02:17:36 <bcos> Out of the big 3 (BIOS, UEFI and ACPI), BIOS and UEFI are the least worst.
02:17:55 <zid> so I'll just stick to bios as long as I can
02:18:24 <bcos> Wait..
02:18:32 <bcos> zid: How is secureboot trivially bypassable?
02:18:49 <zid> You can just fake it being enabled, it's not *actually* secure
02:18:56 <zid> it's literally "set flag and pretend secureboot happened"
02:19:20 <bcos> Oh. Not bypassable by the OS
02:19:32 <zid> I mean, that too
02:19:39 <zid> there are published shims that will boot anything
02:19:39 <adu> it's also trivially bypassable if you have the bios password
02:19:51 <zid> and most bioses let you rekey them
02:20:43 <bcos> The shims have to be locked down somehow (to minimise the threat of Microsoft revoking the key)
02:20:58 <bcos> ^ 'tis why Linux added a whole pile of digital signature stuff
02:21:12 <zid> except they're just not, because otherwise linux couldn't change
02:21:19 <zid> it'll boot anything that even remotely vaguely resembles linux
02:21:22 <zid> or grub
02:21:34 <zid> and I can kexec/chainloader/whatever I like from there
02:21:41 <zid> It's not secure it's just hassle
02:21:41 <bcos> If you disable secureboot? Sure
02:21:47 <bcos> Kexec() got disabled
02:22:06 <bcos> (then patched to check keys and re-enabled)
02:22:41 <zid> did you read the thread for that
02:22:48 <zid> the people wanting kexec disabled had no idea lol
02:23:10 <bcos> Not sure which thread
02:23:22 <zid> the "we should disable kexec / require signing / blah" one
02:23:32 <zid> It's a good read just because of hilarity
02:23:47 <bcos> On Linux kernel mailing list?
02:23:58 <zid> yea
02:24:37 <bcos> Not sure if I saw it - I think what I'm remembering is this: https://lwn.net/Articles/603116/
02:27:29 <zid> It basically boiled down to "we should stop exploited machines kexecing insecure payloads" people completely ignoring that if someone has rooted the machine, there's literally a billion ways they could just start a new kernel with the "we secure booted lol" flag set
02:27:41 <zid> and several people pointing that out
02:29:36 <doug16k> if you are a real vendor you want the key that is preloaded to work, you can't have a malware loader bootloader (it has to verify authenticity of what it loads too). otherwise your key is revoked and nobody can install your product
02:29:40 <bcos> You think that "after the security failed (system rooted) there's no security, so we shouldn't bother trying to prevent the system from being rooted" is acceptable logic?
02:30:08 <zid> If the security has failed, the security has failed
02:30:10 <doug16k> nobody can install without screwing around I mean
02:31:35 * bcos mostly wants secureboot, but with firmware required to provide a "key not recognised, enter firmware's admin password and click button to add key" dialog box
02:31:55 <zid> As long as I can start qemu on that machine, with a faked 'secureboot happened flag', any extra security that doesn't address *that* is fairly useless
02:32:08 <doug16k> if you have physical access you can do the "forgot admin password" procedure right?
02:32:34 <bcos> doug16k: If you have physical access everything gets scary
02:32:38 <zid> The software I wanted to run under secureboot but couldn't because of secureboot is now entirely defeated
02:32:41 <doug16k> right, becomes futile
02:33:17 <doug16k> so it only works up to a point. I accept it
02:33:26 <bcos> zid: Except now you don't have any access to the real hardware or the data it contained, and any authentication checks (e.g. TPM) fail and nobody on the LAN will talk to you
02:33:50 <immibis> bcos: they're saying that after the security failed (system rooted) they want to try and stop the attacker who has full access to everything from doing certain things. but it won't work because they can find another way to do it
02:34:01 <doug16k> yes, what you do is make it a data loss mechanism, and make it so the full drive encryption is lost if you reset it
02:34:44 * bcos nods
02:35:10 <immibis> if you disable kexec the root user can load a kernel module that implements kexec, or use /dev/mem, or load a kernel module that implements /dev/mem and then use /dev/mem
02:35:34 <zid> yea, which they've slowly been mitigating
02:36:38 <zid> but there's still a bunch of holes so for now it's just useless
02:38:24 <zid> It's not even any better on windows, I've got a whole bucket of drivers windows will load that'll let me bypass all this :P
02:39:39 <bcos> Only if you're window's admin and disable digital signature checks on drivers?
02:39:45 <zid> no
02:40:37 <zid> Just don't let it know that capcom.sys was revoked
02:40:41 <zid> etc
02:41:48 <adu> lol
02:42:48 <immibis> bcos: can you do that on a secure boot system?
02:43:00 <immibis> cause that would be equivalent to what you were talking about on linux
02:43:28 <bcos> immibis: Can I do what on a secure boot system?
02:43:48 <immibis> disable driver signature checks
02:45:09 <bcos> Not sure (I'm no Windows driver developer)
02:46:00 * bcos doesn't even have a real computer that currently boots with UEFI - been switching to "BIOS boot" for OSdev reasons
02:58:45 <adu> I have 3 (2 apple macs and 1 ASUS)
03:03:39 <adu> huh, trying to see if I could find "Asus" using dmidecode
03:04:12 <bcos> Case sensitive?
03:04:13 <adu> it says Mfr: ASUSTeK
03:04:19 <zid> Yep
03:04:29 <adu> then Location in Chassis: "To be filled by O.E.M."
03:04:37 <zid> always is
03:04:40 <bcos> Heh
03:04:49 <zid> I've yet to see a system builder fill out software fields like that
03:04:52 <adu> I put the motherboard, cpu, case together myself
03:04:55 <zid> Huáshuò diànnǎo gǔfèn yǒuxiàn gōngsī; stylised as ASUSTeK or ASUS
03:04:58 <zid> fwiw
03:08:49 <adu> does that make *me* the OEM?
03:11:42 <bcos> adu: It makes you the OEM of the computer (but not the OEM of the parts)
03:12:08 <bcos> Mostly that field is intended for people like DELL or HP that sell whole systems
03:12:13 <adu> I want to fill in the dmi fields :)
03:12:21 <zid> system builders, as I mentioned
03:12:26 <zid> and even they rarely bother
03:12:36 <adu> Location of Chassis: "Next to Andrew's Cat"
03:13:44 <bcos> Location of motherboard in chassis (not location of chassis)
03:14:36 <zid> "Screwed in"
03:14:46 <bcos> - probably supposed to be something like "at the bottom chassis" or "up the right hand side of chassis"
03:16:00 <bcos> ..so that when maintenance dude opens the case they know where to look, because motherboard are hard to find
03:16:02 <bcos> ;-)
03:16:29 <zid> http://bash.org/?5273
03:17:51 <bcos> Heh :-)
03:36:44 <adu> what should my SKU number be?
03:36:51 <zid> 0xB00B
03:36:55 <zid> in decimal
03:36:56 <adu> lol I like it
03:37:27 <bluezinc> works well with 0xCAFEBABE
03:37:55 <adu> 0xFEEDFACE is my fav
03:39:14 <bluezinc> see 0xB00B with 0xCAFEBABE, 0xFEEDFACE with 0xDEADBEEF.
03:39:25 <bluezinc> or, the story of getting a hamburger.
03:39:44 <adu> lol
03:40:27 <bluezinc> x
03:40:45 <adu> 0xB105F00D
03:41:35 <adu> https://www.theregister.co.uk/2015/07/08/facebook_casts_a_hex_on_dns/
03:42:13 <adu> ipv6 squatting for yourself, how 1337
03:42:34 <zid> [04:42] * Dns resolved muf.violates.me to 2001:470:1f09:1cfb:0:b00b:b00b:b00b
03:42:45 <adu> lolol
03:43:50 <adu> oh 0xFEEDBULL is clever
03:44:00 <adu> only works in C*
06:43:06 <geist> yah i've generally moved all of my modern machines to uefi only, with no CSM
06:43:14 <geist> thus far hasn't given me much trouble
06:52:22 <AerodynamicBrick> I just measured a 37 pF cap as 60 pF with a fukn arduino
06:52:25 <AerodynamicBrick> holy shit
06:52:55 <AerodynamicBrick> took forever to setup a way to measure like this with a fucking potato
07:03:15 <renopt> hey while you're at it you should also measure a real potato
07:04:45 <AerodynamicBrick> this
07:10:54 <zid> so your margin of error is like 50%?
07:11:23 <zid> what did you do, put a bleed resistor across it and wait for it to go below logic level high?
08:03:22 <jjuran> zid: `traceroute bad.horse`
08:10:31 <zid> why
08:10:46 <zid> is it a ttl blackhole
08:11:28 <zid> looks like it
08:12:06 <zid> oh it stopped after 30, rude
08:40:37 <Kazinsal> that is an impressive rDNS hack
08:42:06 <Kazinsal> big fan of the fact that it uses what appears to be half of a /27 to pull off
08:43:21 <Kazinsal> ah it's part of a /22 announced as AS62512
08:45:52 <Kazinsal> I'd love to be able to do something like that but IPv4 space is expensive :(
08:46:07 <Kazinsal> $26 USD/IP in a /24
08:46:35 <jjuran> Mine finished at 40
08:46:46 <zid> your isp is terrible:P
08:46:56 <zid> I got to backbone in 8 hops
08:47:29 <zid> then telia to atlanticmetro for a few, then bad.horse
08:47:40 <jjuran> I got to a node with "bad" in the name at 3 hops :-D
08:48:22 <FireFly> I get to bad.horse in 13 hops, to the last one in 30, it seems
08:48:40 <Kazinsal> 2 hops inside my network, 5 in my ISP's, then atlanticmetro until it hits AS62512's dmarc
08:48:56 <jjuran> I get to bad.horse in 13 hops, but the last one is 40
08:49:41 <zid> https://gist.github.com/zid/52e24e910cb2393cc4dc7b463383e33e
08:50:26 <Kazinsal> yeah I seem to only get 30 hops out of mtr
08:50:30 <jjuran> And I was knoecked offline for over 2.5 hours, so yeah, my ISP is terrible :-P
08:50:53 <zid> it takes me 13 hops to get there, and I have to go to london, then new york, then to wherever that is, presumably, given the latency
08:50:56 <zid> and the name atlantic metro
08:51:00 <aalm> you-re.saddled.up
08:51:12 <zid> am I supposed to get more cute names than I got
08:51:17 <aalm> maybe
08:51:24 <aalm> he-s.bad
08:51:28 <jjuran> zid: You're missing the last 12 :-(
08:51:39 <zid> his network did it not me
08:51:47 <aalm> my last was 45
08:51:56 <jjuran> Watch "Dr. Horrible's Sing-Along Blog" for the rest (and the context)
08:55:04 <doug16k> I get 46
08:55:18 <doug16k> traceroute -m 255
09:02:39 <doug16k> tried my system qemu today, virtio msi and msi-x works fine. qemu from master, msi and msix are not there
09:04:59 <doug16k> was a total wild goose chase
09:08:54 <zid> did you bisect it down and get the commit message
09:28:21 <doug16k> no
09:39:24 <sergedx> Spent a lot of time debugging issues with reading GDTR in my EFI application, and finally found the problem. Under x86_64-w64-mingw32-gcc I need to use __attribute__((gcc_struct,packed)) instead of __attribute__((packed)), or specify -mno-ms-bitfields in CFLAGS. Maybe we should add this to "common problems" on this page? https://wiki.osdev.org/UEFI_Bare_Bones
09:40:51 <zid> I thought -mno-ms-bitfields was all-over everything for anyone who used mingw
10:14:16 <bauen1> regarding the whole find memory for early boot thing: turns out, the highest of kernel and modules doesn't cut, since grub can (and will) put the multiboot information after the modules
10:14:37 <bauen1> and if you memset correctly you won't have any memory map information left to populate the PMM with
10:16:56 <bauen1> an example: https://i.imgur.com/24VMiq1.png (the kernel ends somewhere around 10c660 and the bitmap is aligned to 0x1000, writing to the bitmap will overwrite the multiboot information (mbi))
10:17:55 <zid> yea don't start scribbling over random bits of memory inside the bootloader :P
10:18:13 <zid> I copy my E820 to a statically declared buffer before I do that
10:18:45 <bauen1> statically declared only works for so many entries lol
10:19:07 <bauen1> for 32 bit i could just have the bitmap in the bbs, since the biggest size possible should be 4gb which isn't too much
10:19:14 <zid> And if they want more entries than a page, they can piss off :P
10:19:22 <bauen1> lol
10:19:37 <zid> "Your bios is shit, email me for a special version" is perfectly adequate use of my dev time
10:19:51 <zid> coding around things that will almost certainly never happen, before anyone actually reports it? meh
10:20:42 <bauen1> idk i'm planning to write a proper kernel that actually does thinsg the right way and doesn't try to cut corners but ....
10:21:38 <zid> Enjoy getting nowhere, then?
10:21:43 <zid> Handling everything is handling nothing
10:27:07 <Kazinsal> plan for edge cases, but don't pre-emptively try to handle them
10:27:26 <bauen1> i've already encountered the edge case lol
10:28:05 <jjuran> If you weren't getting a failure without the corner, how do you test it?
10:28:11 <jjuran> oh
11:06:17 <doug16k> made a tiny kernel that looks for missing virtio MSI-X. now gotta wire that up to bisect
11:07:33 <doug16k> system qemu vs master -> https://gist.github.com/doug65536/005ac6ba38fad6f8890ef2f4f0b8df40
11:08:30 <zid> ah that's a cute way of automating the bisect
11:08:33 <zid> I'd have just done it by hand
11:10:53 <doug16k> https://github.com/doug65536/qemu-msibug
11:14:00 <doug16k> zid, done what by hand?
11:14:05 <zid> the bisect
11:14:14 <doug16k> oh
11:14:32 <doug16k> it has to clean build qemu repeatedly
11:14:40 <doug16k> I'm not sitting through that
11:14:51 <zid> I can handle building qemu 8 times, takes like a minute or two doesn't it
11:16:21 <doug16k> so I'm supposed to track a binary search through git history by hand, then debug into my real kernel and look for the use_msi == false and start over manually?
11:16:28 <zid> git tracks the binary search
11:16:37 <zid> that's what the bisect *does*
11:16:39 <doug16k> ya, when you build a thing that fails or succeeds
11:16:46 <zid> no, git bisect --god
11:16:49 <doug16k> what is your "by hand" isect
11:16:50 <zid> good*, or bad
11:17:10 <doug16k> no it might take forever
11:17:22 <zid> it's a binary search, it takes log2(commits in range)
11:17:24 <doug16k> and I don't want to debug into it over and over
11:18:15 <jjuran> Git is so sharp, it bisects deities?
11:18:18 <doug16k> easily months range
11:18:31 <zid> okay it took 3 minutes realtime to install qemu from emerge
11:18:37 <zid> on -j4 with -O3
11:18:44 <zid> including make install, configure, etc
11:18:49 <zid> downloading the tarball
11:18:51 <doug16k> ya, now what
11:19:08 <doug16k> now manual crap
11:19:12 <zid> yes
11:19:19 <doug16k> I just automated it
11:19:24 <doug16k> what now do it manually?
11:19:30 <zid> pardon
11:19:47 <doug16k> this is a unit test
11:20:02 <doug16k> things like this have a way of being reintroduced into the code
11:20:24 <zid> surely the unit test belongs to qemu :P
11:20:33 <doug16k> I have a bmi test too. I can do make run and poof, in about 300ms it says passed or failed
11:20:40 <doug16k> hell no
11:20:47 <zid> yep, that would have been the 'manual' part, 300ms :P
11:20:48 <doug16k> they don't know what unit test means
11:21:28 <doug16k> you are saying to debug into my kernel over and over and find which commit it is, by hand
11:21:33 <zid> no
11:21:35 <doug16k> ye
11:21:38 <zid> I'm saying I'd have just done it manually
11:21:43 <doug16k> how do I know if it is --good or --bad
11:21:43 <zid> instead of made it interface directly to git
11:21:52 <zid> I'd have made it go red or green or something, in 300ms
11:21:57 <zid> and just typed 'good' or 'bad'
11:22:03 <doug16k> ...
11:22:11 <zid> I wouldn't have thought to make it dump to a log and interface it to the bisect
11:22:21 <doug16k> you can give bisect a script. it runs it and the script exit code says whether it was good or bad
11:22:23 <zid> hence, that's cut
11:22:25 <zid> yes I know
11:22:25 <doug16k> then it just blasts through it
11:22:33 <zid> That's why I said it was cute
11:22:47 <doug16k> cute? bit condescending don't you think?
11:22:47 <zid> I didn't say "That's amazing I didn't know you could do that", or "You shouldn't have done that"
11:22:51 <zid> I was admiring you
11:23:06 <zid> If you want to be a miserable bastard go for it man
11:26:03 <doug16k> I thought you were telling me what I did was pointless and you were amused by my stupidity that I made a script to automate it for the last 20 minutes
11:26:17 <zid> Yea I didn't say anything at all like that
12:06:18 <doug16k> turned out to be 5725 commits, 13 steps
12:13:42 <doug16k> it's fun to sit here and have the machine do all the work anyway :D
12:13:44 <doug16k> 3 steps left
12:14:55 <doug16k> aha, "virtio helper for registering virtio device types" hmmmmm
12:16:13 <bcos> doug16k: The sad part of this kind of thing is that you'll need to allow many years before any fix made this week propogates to everyone else's computer
12:17:09 <bcos> (e.g. I'm incredibly lazy/reluctant to update software - probably haven't updated anything on this computer in the last 6 years)
12:18:22 <doug16k> this commit broke virtio MSI and MSI-X IRQs: https://gist.github.com/doug65536/956a7867533dbc5c1c3ce796b712c539
12:20:18 <bcos> Heh - looks a little "nepotistic" - written by ..@redhat, reviewed by ...@redhat, ... by ..@redhat, ..
12:21:46 <bcos> ..like, 4 people in the same little office cubical (and nobody outside that cubical) were involved
12:35:42 <doug16k> man I wasted so much time on this, scouring my pci and ecam code, then wasting time adding non-MSI-X interrupt handling to virtio...
12:36:16 <doug16k> I should check the system qemu right away when things break
12:36:32 <doug16k> zid, sorry I misunderstood
12:40:52 <doug16k> my top level bisect script (that I hand to git bisect run) is a total hack but in case anyone is curious -> https://gist.github.com/doug65536/ed1fc5178849d26c82d660cec6a887d2
12:41:55 <doug16k> needs more "|| exit" but it was good enough
12:47:41 <doug16k> || exit means, if the command on the left fails, exit this script with that failing program's exit code
01:42:54 <mlugg> Hi, I'm looking at the ACPI spec (specifically, the MADT structure), and I've not been able to find any info on what the SAPIC interrupt model is (referenced in section 5.2.12.9 amongst others in ACPI spec v6.3). Can anyone point me in the right direction? Thanks :)
01:43:36 <bcos> mlugg: SAPIC is (more or less) the equivelent of an IO APIC for Itanium systems - won't exist for 80x86
01:43:43 <mlugg> Ah, okay, thanks
01:44:00 <mlugg> Probably explains why I can't find much info on it
01:47:56 <mlugg> Annnd I've just come across x2APIC - afaict it's just a newer standard that supports more CPUs, or is there more to it?
01:48:47 <bcos> Yes - that's for 80x86, and mostly extends the "APIC IDs" from 8-bit to 32-bit so you can have more than 255 CPUs
01:49:24 <bcos> (also has a few other differences - faster register access to local APIC through MSRs, a "directed EOI" feature to avoid broadcasting EOI to all IO APICs)
01:49:47 <bcos> *to all APICs
01:52:11 <mlugg> How do systems support that in a backward compatible way? Do processors have entries of both types, or is it just not backwards compatible?
01:54:17 <bcos> The first "255" CPUs (less if there's more than one IO APIC) get 8-bit IDs so that if an OS doesn't support x2APIC it'll still work (just without all CPUs)
01:54:50 <bcos> ..and if an OS does support x2APIC it can switch those CPUs from "xAPIC mode" to "x2APIC mode" and start the other CPUs (that are already in "x2APIC mode")
01:55:32 <mlugg> Okay, that makes sense
01:55:34 <mlugg> Thanks
01:56:11 <heat_> is x2APIC just that?
01:56:57 <heat_> because that seems pretty useless for everything that isn't a huge server/supercomputer
01:57:35 <bcos> Faster is always nice...
01:58:02 <heat_> oh it's faster?
01:58:20 <heat_> ah, I can't read sorry
01:58:57 <bcos> Historically, "huge server stuff" ends up being cheap home stuff in ~10 years too though
01:59:32 <bcos> (e.g. average smartphone is more powerful than the average super-computer was 20 years ago)
01:59:44 <bcos> (or something like that)
02:02:14 <bcos> Hrm - Cortex-a53 @ 1 GHz = about 8 GFLOPs = about this thing from 1995: https://en.wikipedia.org/wiki/Fujitsu_VP2000
02:03:08 <bcos> D'oh - superceded in 1995, actually from 1988, so more like 30 years
02:03:17 * bcos shrugs
02:12:03 <mlugg> bcos: So, triple-checking I've got this right: The first 255 (or maybe less) CPUs don't have local x2APIC structures in the MADT, but just regular APIC ones, and you have to enable the x2APIC features, but the rest (with IDs that can't be accessed with 1 byte) start in x2APIC mode
02:12:26 <bcos> Yes
02:12:49 <mlugg> Okay, tyvm for the help
02:13:09 <bcos> :-)
02:35:38 <bauen1> amazingly, finding memory for the pmm properly isn't as hard as i though it would be, only ~120 lines of code (including ~30 of comments and uneeded debug statements) and adding multiboot module support is trivial
02:36:35 <bauen1> and it's (probably) safer than just trying to put the pmm at the end of the modules / kernel since that can/will overwrite the multiboot information
02:39:45 <heat_> bauen1: i mean yeah but it depends on how your kernel bootstraps itself
02:40:02 <heat_> once you get paging rolling it's going to be a bigger pain in the ass
02:40:45 <bauen1> it's only used for the allocation of the bitmap, after that everything is easy
02:40:56 <heat_> you're using a bitmap?
02:41:17 <bauen1> for the start yes, but i might switch to something more efficient
02:43:45 <heat_> I've personally used every big page allocation algorithm and I can tell you that by far the best one is just to use a page list
02:45:50 <heat_> I've set it up in a way that I set up "page arenas" which are basically just groups of 1024 pages and the list of pages is ordered by address so I can easily grab n > 1 pages
02:45:58 <heat_> it's nice.
02:49:05 <bauen1> interesting, i'll look into it
02:49:28 <bauen1> i need to read a bit of theory on operating systems, i don't want to write myself into a corner again
02:50:26 <heat> personally I believe you can't really predict what you're going to need for your OS
02:50:31 <heat> you kinda just pick it up from experience
02:51:23 <heat> I have LOADS of code that was written a few years ago and present heat thinks it's awful and messy and bloated and spaghetti
02:51:34 <bauen1> yeah
02:51:39 <heat> past heat thought it was good/okay because he didn't know better
02:51:58 <heat> you kinda rework these areas when you really need to add/improve/fix things
02:52:09 <bauen1> last commit to myunix version 2 is only a few months back, and i'm already wondering how i've managed to write such terrible C code
02:54:50 <heat> oh yeah I've written pretty bad code in the past
02:55:04 <heat> since OSDeving was my first big and real project
02:56:21 <bauen1> i've only really started to write a lot of c code for osdev
04:10:10 <bauen1> maybe i should start writing a blog about the stuff i programm, just so i write better code and more comments ._.
04:44:02 <lukos> hello
05:00:34 <bauen1> hello
05:34:57 <geist> hola
05:35:29 <lldd_> hola hola
05:36:58 <vdamewood> Olá
05:59:26 <Vercas_> Dealing with a bizzare bug in code I haven't touched in years, literally.
06:00:05 <Vercas> Can't tell if regression or GCC shafting me again because I've got UB.
06:22:17 <heat> Vercas: when in doubt, implement ubsan
06:23:01 <Vercas> heat: Got any pointers for me? Wiki article? Blog post? GCC docs?
06:24:22 <heat> Vercas: sortie implemented it, it's in sortix
06:24:41 <heat> I kinda just used that and adapted it for my kernel
06:26:19 <Vercas> heat: I found it, cheers. :D
06:26:25 <heat> :)
06:46:27 <Vercas> I tried building with `-fsanitize=undefined` (before adding ubsan stuff) and my terminal turned white with linker errors. :D
06:48:09 <Vercas> Literally over 10,000 of them. Can't even see the beginning of the error list in my terminal.
06:51:07 <bauen1> there's only ~10 functions you need to implement
06:51:13 <bauen1> simple functions too
06:51:21 <Vercas> I know.
06:51:56 <bauen1> there's also an option to just have gcc trap (which should work in kernel space too) if you're lazy
06:53:47 <Vercas> Whaddya mean by trap?
06:57:13 <bauen1> Vercas: there's -fisolate-erroneous-paths-dereference -fisolate-erroneous-paths-attribute (maybe -ftrapv) and -fsanitize-undefined-trap-on-error (this one being the most important one)
06:58:50 <Vercas> That doesn't really answer my question, bauen1. Trap as in, what, invoke interrupt 3?
06:59:52 <bauen1> oh
06:59:57 <bauen1> it calls __builtin_trap
07:00:36 <Vercas> Which I suppose I've got to implement, right?
07:00:53 <bauen1> gcc provides one that executes an illegal instruction
07:01:07 <bauen1> maybe you can implement your own
07:01:14 <bauen1> i've never used it, i just implemented ubsan
07:02:21 <Vercas> I see.
07:03:01 <heat> __builtin_trap just ud2's
07:03:12 <Vercas> I think my only choice here is to use the debugger to report the errors... But that will just suck arse if I've got UB in the debugger's path. :l
07:03:54 <heat> just add ubsan man
07:03:56 <heat> it's useful
07:04:02 <bauen1> ^
07:04:07 <Vercas> I am...
07:04:20 <Vercas> But I must report the UB somehow, don't I? :l
07:04:26 <heat> printf
07:04:37 <Vercas> heat: Great unless I have UB in the printf code. :D
07:04:51 <bauen1> someone should probably write a libubsan for kernel space so we don't all have to implement it (and just have it call ubsan_panic() which is provided by the kernel)
07:05:00 <bauen1> true
07:05:02 <heat> you're always possible to get somehow fucked
07:05:25 <Vercas> bauen1: Sortie's implementation looks close to what you want.
07:05:33 <heat> in my case I can just detect the ub since it just hangs on a lock
07:05:38 <bauen1> you could look for any possible undefined behaviour in printf (after compiling it) and then check that in printf
07:06:30 <Vercas> I definitely need a way to ignore UB inside UB handling code... :D
07:06:33 <bauen1> actually, you can't check every undefined behaviour i think
07:06:35 <bauen1> you can
07:07:33 <bauen1> __attribute__((no_sanitize_undefined))
07:07:39 <bauen1> i wouldn't add it to printf though
07:08:02 <heat> Vercas: gcc doesn't sanitize ubsan functions I believe
07:08:24 <Vercas> I mean functions called by ubsan functions too.
07:08:42 <Vercas> No amount of static analysis will help GCC figure out what they will be in my case.
07:08:43 <heat> as I said, don't mind that
07:09:01 <Vercas> bauen1: Wait, that's a thing?
07:09:35 <heat> Vercas: In my case it just hangs on a tty lock and that's that
07:09:36 <Vercas> bauen1: Holy shit it is, thank you!
07:10:09 <heat> if I see that it hanged, I connect with gdb and 'bt' my way to the error
07:10:28 <Vercas> heat: Yeah, that's not exactly an option for me right now... I'll work on that, though.
07:11:14 <heat> there's no need to over-engineer it, especially considering you'll have to look everywhere your ubsan touches and un-ubsan it
07:11:31 <heat> and that is essentially very very hard
07:12:03 <bauen1> and very error prone
07:12:11 <heat> right
07:12:16 <bauen1> since you now need to make sure you don't cause actually undefined behaviour
07:12:22 <bauen1> which can cause interrupts and other fun stuff
07:13:10 <heat> in my case my printf code path touches all kinds of code(including memory management and scheduler stuff)
07:13:35 <heat> that would mean I would have to turn off coverage of a very large part of the kernel
07:14:19 <bauen1> why do you need memory management inside printf ? i just allocate a buffer on the stack that is large enough for any number (well, i just call putc instead of making it a proper printf but still) ?
07:15:26 <Vercas> heat: I've got a thin debugger interface in my kernel, and the printing code path is rather minimal.
07:16:28 <heat> bauen1: printf has a static buffer, but it then touches the tty and terminal code
07:16:48 <heat> and the video terminal uses message passing plus a dedicated render thread to render stuff
07:17:19 <heat> therefore I need malloc to allocate message structs and scheduler code to wake up threads
07:17:38 <bauen1> nice
07:33:57 <Vercas> Need to implement __ubsan_handle_type_mismatch_v1
07:42:15 <doug16k> bauen1, I assume you don't handle %8000d then?
07:42:57 <doug16k> you could I guess
07:43:40 <doug16k> I do a thing where I decouple the padding and the number so I can fit all the digits and pad
07:46:12 <doug16k> printf("%400000000d", 42) should print 399,999,998 spaces of padding
07:52:53 <bauen1> i just print the padding, i don't store it in a buffer
07:53:17 <doug16k> good
07:54:06 <doug16k> sooner or later someone will pass * and give a crazy number. it's important that that scenario not go nuts
08:25:56 <Vercas> __ubsan_handle_nonnull_return_v1 is all I've got left to implement... Jesus this is such a chore. :C
09:39:54 <Vercas> I'm stuck, I have no idea how to convince GCC that a specific piece of code works. It's not happy that I use reinterpret_cast to get a pointer from an integer, then construct an object in place there. :l
09:52:53 <Vercas> It seems to think there is insufficient space for my object.
11:03:23 <Vercas> God damn it, the attribute that tells GCC not to add ubsan shit in a function doesn't actually work.
11:05:46 <heat> it does
11:05:55 <heat> I use it
11:10:01 <doug16k> Vercas, if you alignas that integer to the same alignment as that construct in place, does it help?
11:10:19 <Vercas> Well, it's definitely aligned.
11:11:13 <doug16k> thought it might help convince it that the code is defined
11:13:01 <Vercas> I'll keep trying to convince it...
11:13:32 <aalm> try harder
11:13:38 <eryjus> I am having a problem with the APIC. When I route the LAPIC timer through the 8259 PIC, things work; when I route wither the 8253 PIT or the LAPIC timer through the IOAPIC, I get a double fault (but not a triple). When I do not enable interrupts things obviously do not fault. As best as I can figure, I have something wrong in the code that sets up the redirection table, but damned if I cannot figure it out. Any suggestions on what
11:13:38 <aalm> .theo
11:13:38 <eryjus> to look at?
11:13:38 <glenda> Don't waste your money on a false ideal by someone who misunderstands modern hardware and the market forces.
11:13:52 <heat> doug16k: You implemented kasan right?
11:14:11 <doug16k> it feels like lately gcc is starting to introduce warning semantics that point out problems that occur on some arch, not necessarily this arch
11:14:15 <doug16k> heat, yes
11:14:40 * heat is trying to implement support for it
11:15:05 <heat> what's the difference between _asan_load and _asan_load_noabort?
11:15:18 <doug16k> it always generates _noabort calls for me
11:15:22 <doug16k> never calls the other
11:15:36 <heat> linux just aliases both but I thought there might be something to it
11:15:38 <doug16k> the other are probably only for user mode
11:16:19 <heat> like, I'm thinking right now and I don't know how I'm going to pull this off
11:16:24 <doug16k> good to know, if it suddenly calls it I'll try aliasing
11:16:40 <heat> considering I have a huge amount of address space
11:16:50 <doug16k> I support the entire 256TB
11:17:01 <heat> do you do the 1 byte = 8 bytes thing?
11:17:07 <doug16k> yes
11:17:24 <doug16k> and it's a radix tree, very much like 4-level x86-64 paging
11:17:35 <doug16k> it practically IS that, but no flag bit stuff in low 12 bits
11:17:49 <doug16k> then I can represent 128 terabit bitmap sparsely
11:17:55 <doug16k> 256 terabit*
11:18:35 <heat> hmm
11:18:37 <doug16k> there's a pool of pages and it takes them with bump alloc on demand
11:19:03 <heat> how exactly is a radix tree better than having it all mapped like linux does it?
11:19:13 <doug16k> all what mapped?
11:19:24 <heat> the bitmap
11:19:40 <doug16k> mine works from the entry point. no fancy memory manager needed
11:19:46 <heat> it's just a plain simple array and it does ptr arithmetic to get there
11:19:53 <doug16k> have fun turning on kasan late
11:20:02 <doug16k> after you missed a bazillion stores
11:21:01 <doug16k> I initialize it approximately one screenful of assembly from the entry point. basically I dispatch BSP/AP then do asan asap on bsp
11:21:30 <doug16k> I miss nothing. every access is handled from moment 0
11:21:49 <doug16k> that is my rationale for the way I did it
11:22:14 <heat> hmm
11:22:15 <heat> interesting
11:23:09 <doug16k> if you did turn it on late you could handle it. just be caution and generously mark a lot initialized, it will still handle use after free and weird out of bounds accesses
11:23:27 <doug16k> I went for it working absolutely asap though
11:25:06 <doug16k> you need to put a thing in your free codepaths that clear that area back to uninitialized
11:25:19 <doug16k> free/ whatever your kernel does to munmap, etc
11:27:26 <heat> yeah
11:27:30 <doug16k> it was fun getting it going. it would keep catching accesses I forgot about from my bootloader parameters and stuff. it really works
11:28:07 <doug16k> I didn't tell it that that region was initialized, so it looked like I was reading a bad pointer when I accessed kernel parameter
11:28:17 <heat> I'm looking for really nasty physical memory corruption(and I keep getting some malloc aborts from time to time) and I thought it would be a good idea to add support for kasan
11:28:38 <heat> it's easier than manually checking for bugs everywhere in the kernel(which is a lot)
11:28:42 <doug16k> good idea
11:30:27 <doug16k> you don't have to do the full crazy scale entire address space I did either. just support a limited range that you know covers everything and make it easier to do the fixed map you mentioned
11:31:14 <heat> the thing is that I spread out my address space quite a lot
11:31:28 <doug16k> ah
11:32:15 <heat> so there's kind of a 2TB gap between vmalloc, stacks, heap, physical memory map, etc
11:32:46 <doug16k> nice
11:33:21 <heat> probably means that it's going to be harder to make kasan work though :/
11:42:00 <doug16k> I went straight for a tree like that because that data structure is perfect for extremely large areas of nothing with smatterings of details at arbitrary places. O(1) lookup is nice when you are getting hammered with calls for practically every memory access
11:42:40 <doug16k> the core operation is 4 pointer chases
11:44:39 <doug16k> outside that is the thing that handles operand (mis)alignment and figures out the bitmask representing the operand's memory range. I do aligned fast, and decompose misaligned into a loop of byte ops
11:45:21 <doug16k> well, spanning I should say. an operand spanning one bitmap and another decomposes to byte ops
11:49:25 <doug16k> kasan can be used for some interesting tracing too. it would be neat to do locality analyses using the accesses traced from asan calls