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=1&d=9

Tuesday, 9 January 2018

00:00:00 --- log: started osdev/18.01.09
00:02:14 --- join: heinrich5991 (~hein5991@unaffiliated/heinrich5991) joined #osdev
00:06:16 --- join: bm371613 (~bartek@2a02:a317:603f:9800:391:ed9f:1c09:1285) joined #osdev
00:08:59 --- quit: FreeFull ()
00:10:15 --- join: m3nt4L (~asvos@2a02:587:a019:8300:3285:a9ff:fe8f:665d) joined #osdev
00:12:24 --- join: xerpi (~xerpi@20.red-88-23-237.staticip.rima-tde.net) joined #osdev
00:13:17 --- quit: xerpi (Remote host closed the connection)
00:13:37 --- join: xerpi (~xerpi@20.red-88-23-237.staticip.rima-tde.net) joined #osdev
00:16:21 --- quit: srjek (Ping timeout: 276 seconds)
00:18:26 <geist> and you can definitely get riser cards to house m.2 slots
00:20:04 --- join: shymega (~shymega@torbaytechjam/shymega) joined #osdev
00:35:19 --- join: xerpi_ (~xerpi@20.red-88-23-237.staticip.rima-tde.net) joined #osdev
00:37:42 --- quit: xerpi (Ping timeout: 248 seconds)
00:38:18 --- quit: Belxjander (Ping timeout: 256 seconds)
00:38:32 <doug16k> gamozo, 1TB samsung EVO pro M.2 NVMe
00:38:52 --- join: xerpi (~xerpi@88.23.239.67) joined #osdev
00:39:54 <doug16k> I get about 3.2GB/sec sequential
00:40:34 --- quit: xerpi_ (Ping timeout: 240 seconds)
00:41:14 --- join: xerpi_ (~xerpi@67.red-88-23-239.staticip.rima-tde.net) joined #osdev
00:43:11 <doug16k> I wish they made 2880x1620 monitors
00:43:55 <doug16k> hmm, seems some are available
00:43:58 --- quit: xerpi (Ping timeout: 256 seconds)
00:44:01 <Mutabah> 4K?
00:44:13 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:44:30 <moondeck[m]> thats sub 4k
00:44:41 <Kazinsal> That's one of those odd ones that I don't think has a standard name
00:44:48 <moondeck[m]> 4k is 2160p
00:44:51 <Kazinsal> 2.7K is 2704x1524
00:49:06 --- quit: Arcaelyx (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:49:57 <doug16k> moondeck[m], I know what 4k is
00:51:05 <Mutabah> I was actually more asking if 4K would do, because I know those exist
00:51:10 --- part: grawity left #osdev
00:51:12 <Mutabah> but I guess theey're a little steep price-wise
00:51:14 <moondeck[m]> doug16k_:
00:51:28 <doug16k> I was going to buy this, but it's too big: https://www.samsung.com/us/televisions-home-theater/tvs/4k-uhd-tvs/50-class-ku6300-6-series-4k-uhd-tv-2016-model-un50ku6300fxza/
00:51:29 <bslsk05> ​www.samsung.com: Samsung UN50KU6300FXZA: 50-inch Smart UHD TV | Samsung US
00:51:35 <moondeck[m]> doug16k: yeah, i know, but not sure mutabah knew
00:51:43 <moondeck[m]> he typed "4k?" so i thought he was asking if its 4k
00:51:45 <Mutabah> doug16k: Damn, that's big
00:51:54 <Mutabah> Sorry, I'm a litle derpy atm :)
00:51:56 <doug16k> It's only $1k
00:52:13 <Mutabah> I have a 4K monitor, (about 26" iirc) but that's second hand, no idea what they'd go new.
00:53:54 <doug16k> think this one is too small for 4k? https://www.samsung.com/us/computing/monitors/uhd-and-wqhd/32-uh750-qled-uhd-monitor-lu32h750umnxza/
00:53:55 <bslsk05> ​www.samsung.com: 32" UH750 QLED UHD Monitor Monitors - LU32H750UMNXZA | Samsung US
00:54:00 --- join: ampotos_ (~ampotos@lew31-1-78-247-114-197.fbx.proxad.net) joined #osdev
00:54:14 --- quit: ampotos (Ping timeout: 248 seconds)
00:54:28 <doug16k> if I pick large fonts it will offset the insane pixel density
00:54:41 --- join: kimundi (~Kimundi@p57A89A06.dip0.t-ipconnect.de) joined #osdev
00:55:09 <Mutabah> doug16k: It says "4k" there
00:55:25 <Mutabah> 3840 x 2160
00:55:28 <doug16k> ya
00:56:15 <doug16k> if you go 4k you need huge screen or things will be very small
00:56:56 <doug16k> 36 is probably the upper limit before I have to start looking up too far
00:57:08 <doug16k> or 32 or around there
00:57:08 <Mutabah> Well, I use a 1080p tablet routinely, so I'm good with a high dot density
00:57:20 <doug16k> ya on android, which scales perfectly
00:57:26 --- quit: Belxjander (Ping timeout: 248 seconds)
00:57:43 <doug16k> you could use android on 1000k monitor and it would happily draw 10000 pixel fonts
00:57:59 <Kazinsal> I'm curious as to how 4K monitors are these days but I'm more interested in temporal resolution than spatial resolution
00:58:07 <Mutabah> Ah, no, not android - Ubuntu
00:58:20 <doug16k> that one is 1ms
00:58:22 <Mutabah> (One of the new Toshiba Porteges, basically a tablet with a dock)
00:59:51 <doug16k> my eyes are perfect, and I want to keep it that way :)
01:02:41 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:06:04 <doug16k> 32" is the best flat, super fast, 4k monitor Samsung has
01:06:17 <doug16k> the 50" would be hilarious though
01:07:17 <doug16k> funny thing: the 50" 4k has more pixel density than the 1920x1080 27" that I have now
01:08:38 --- quit: kimundi (Ping timeout: 248 seconds)
01:09:05 --- join: FreeFull (~freefull@defocus/sausage-lover) joined #osdev
01:09:49 --- quit: gdh (Quit: Leaving)
01:11:52 <doug16k> it's shocking how many scammers on ebay are listing their ECC ram as unregistered in the title, when it is clearly registered ram
01:12:09 <Mutabah> What does that mean for ECC?
01:12:23 <moondeck[m]> what does registered do?
01:12:47 <mischief> those bastards
01:12:47 <doug16k> registered memory adds a cycle of latency and drives the signals much stronger, and probably won't work in desktop motherboards
01:13:02 <Mutabah> Ah
01:13:45 <doug16k> every desktop board I've seen specifically says "unregistered" memory only
01:13:52 <doug16k> or unbuffered. same thing
01:14:35 <geist> yah you usually need it for large memory arrays. usually in servers
01:15:05 <doug16k> the register is a buffer, just a more specific term. register as in verilog register - latches data this cycle, drives it to output next cycle
01:15:46 <geist> yep
01:15:46 <doug16k> ya
01:16:00 <geist> yep
01:16:20 <immibis> do servers still need that? i thought they'd kinda moved onto having a normalish amount of memory per CPU, with lots of CPUs
01:17:04 <immibis> and NUMA
01:17:11 <immibis> since ages ago
01:17:23 <doug16k> registered memory has better data integrity
01:19:50 <doug16k> I wanted to blow money on 64GB of ram but I can't find it anywhere. so I am considering a really high end monitor instead
01:21:55 <immibis> it's funny how much design goes into hardware that you never ever see as a programmer
01:22:05 <doug16k> this is the closest I could find: https://www.kingston.com/us/MemorySearch/MemoryType?MemoryType=ValueRam&DIMMType=Unbuffered&ErrorCheck=ECC&Speed=2400MHz&Capacity=16&ModuleType=DIMM
01:22:12 <bslsk05> ​www.kingston.com: Memory Type Search
01:22:17 <doug16k> 2666 doesn't even exist
01:22:31 <immibis> like you think the motherboard would
01:23:05 <immibis> like you'd think a motherboard would just be a backplane connecting everything together according to intel's specifications* but it's actually a complete thing in its own right and it's the root of a lot of the design
01:24:03 <immibis> or how when you press the power button on your laptop you're signaling a microcontroller programmed by the laptop manufacturer
01:24:09 <immibis> which is not standard in any way
01:24:27 <doug16k> the buy links there take you to dumbass resellers that can't be bothered to maintain a working link from the manufacturer
01:25:01 <immibis> do we have paging over ethernet yet?
01:25:09 <immibis> or how about paging over RDMA
01:25:22 <immibis> you could write the first implementation of paging as a service
01:25:23 <doug16k> immibis, put the swapfile on a network mount. done
01:25:35 <immibis> doug16k: but does it actually work or does it deadlock the first time you run out of memory?
01:25:42 <doug16k> why wouldn't it work?
01:25:51 <immibis> well because the network filesystem code might need to allocate stuff
01:26:07 <Kazinsal> As long as your network block/network filesystem protocol isn't crap and buffers properly you should be in the OK
01:26:08 <immibis> i'm pretty sure linux is full of hacky flags to deal with cases like that
01:26:09 <doug16k> it won't wait until you have nothing then page
01:26:15 <Kazinsal> I mean, OK is relative
01:26:21 <immibis> doug16k: not on purpose but it's possible
01:26:24 <mischief> immibis: maybe you want RoCE
01:26:41 <immibis> like a "i'm a network filesystem, please give me memory reserved for network filesystems" flag
01:26:49 <doug16k> the local filesystem code might need to allocate stuff too
01:26:51 <immibis> (IIRC from LWN articles; I haven't actually looked)
01:27:29 <immibis> it's not truly done until i can have my pagefile on S3
01:27:59 <doug16k> I'm entertaining the idea as a joke. realistically, even swap to an SSD is complete crap
01:28:50 <doug16k> you could swap to a plotter... and have a webcam read it back in. just have to feed it a new roll of paper once in a while
01:29:10 <doug16k> just need to implement plotfs
01:30:31 <immibis> sure
01:30:40 <immibis> but why a plotter? make it a 3d printer and we've got a deal
01:30:59 <immibis> it's the 21st century doug
01:31:00 <immibis> and you're lagging behind
01:31:12 --- join: bal_ (05391581@gateway/web/freenode/ip.5.57.21.129) joined #osdev
01:31:14 <bal_> hello
01:31:23 <doug16k> I thought a plotter was ridiculously slow enough, but you took slow to the next level for me
01:31:39 <izabera> are plotters slow?
01:31:53 <doug16k> yes
01:31:54 <izabera> like, slower than regular printers?
01:31:56 <Kazinsal> They have to do vector graphing on absolutely massive amounts of paper.
01:31:59 <moondeck[m]> hi there
01:32:01 <doug16k> much slower
01:32:08 <izabera> never used one or seen one in action
01:32:11 <Kazinsal> They are slow as hell but create fantastic vector printouts at massive scales.
01:32:17 <immibis> bal_, can you believe doug doesn't like the idea of swapping to a 3d printer?
01:32:20 <doug16k> the stepper motors make very interesting sounds though
01:32:23 <bal_> I have some doubt about: 1) is segfault generating page fault? 2) why the same very simple program has different page fault count during different run?
01:32:54 <immibis> a segfault is triggered by a page fault for a page that isn't supposed to be valid (as opposed to one that is valid but is swapped out, for example)
01:33:02 <Kazinsal> Or a protection fault\
01:33:14 <immibis> or that
01:33:14 <bal_> as simple I mean: int main() { char *x; x[1] = 0; }
01:33:45 <Kazinsal> Chances are if that segfaults it's a page fault, yeah
01:33:55 <Kazinsal> A page fault doesn't have to be fatal to the process
01:34:12 <izabera> that's not even guaranteed to fault...
01:34:17 <Kazinsal> True
01:34:20 <Mutabah> bal_: You have invoked nasal demons, your compiler can do whatever it wants there
01:34:28 <doug16k> bal_, what you showed is undefined behavior. it could do anything
01:34:29 <Mutabah> In fact, it should be complaining quite loudly
01:35:08 <immibis> the page fault count is probably different because of OS voodoo; perhaps the second time you run it, linux sees all your executable pages are already cached and just maps them in, whereas the first time it loaded them from disk one-by-one as needed
01:35:15 <immibis> (again, I don't know how linux *actually* does things)
01:35:32 --- join: nzoueidi (~nzoueidi@ubuntu/member/na3il) joined #osdev
01:35:56 <Mutabah> Or just different random stray data being dereferenced
01:36:13 <doug16k> bal_, depending on what garbage happened to be used as the pointer, it may or may not segfault, but it has a high probability of faulting
01:39:43 --- join: kimundi (~Kimundi@dhl1116.cs.uni-dortmund.de) joined #osdev
01:47:42 <bal_> doug16k: also without x[0]=0; it generate different PF count on different run
01:48:21 <bal_> if I run it 10 times, I have a PF count range between 37 and 39
01:48:55 --- quit: hmmmm (Remote host closed the connection)
01:49:13 --- quit: lkolstad (Quit: WeeChat 2.0.1)
01:53:18 <izabera> i think at least part of the problem is that you're running at a too high level
01:53:55 <bal_> I am using perf stat -B ./bin to count them
01:54:05 <izabera> yeah i was assuming you were using perf
01:54:08 --- join: Kimundi_ (~Kimundi@dynip-129-217-119-172.wifi.tu-dortmund.de) joined #osdev
01:54:28 <bal_> anyway, segfault raises a PF?
01:54:45 <izabera> rather the other way around
01:55:04 <bal_> as far as I know, there is a fault and PF handler is called and it decides to call segfault handler which kill the process
01:56:01 <izabera> anyway, there's libc initialization, and linux may or may not map your executable in memory or swap it out at any given moment
01:56:38 <bal_> I think the different PF as due to dynamic linker
01:56:40 --- quit: kimundi (Ping timeout: 248 seconds)
01:56:42 <bal_> not the bin itself
01:56:57 <bal_> I should try to compile it statically
01:57:15 <izabera> you would have more control if you were mlocking your entire memory, then reading the pf counter, then accessing the page you think will fault, then checking again the pf counter
01:58:19 <izabera> well i mean, not your *entire* memory... that would mean no pf would ever happen... just the memory that you want to touch...
01:59:28 <izabera> it's kind of disappointing that linux doesn't provide a way in userspace to know if a page is in memory or swapped out
01:59:34 <bal_> how can I do it in the code?
01:59:41 <bal_> can I calculate PF in the code itself?
02:02:05 <doug16k> performance tools aren't perfect. they aren't know for giving exactly correct results
02:02:17 <doug16k> known*
02:03:45 <doug16k> when you run a program, it doesn't copy the executable into memory, it maps it into memory and demand pages in the pages that get touched, and perhaps some that didn't actually get touched.
02:04:55 <doug16k> there will be plenty of page faults in a completely innocent perfect program that doesn't segfault
02:05:14 <bal_> sure
02:05:27 <bal_> but I think that this program fits in one page
02:05:40 <bal_> or 2 at least, because compiler produces big bin
02:05:49 <doug16k> also, when you allocate memory, it doesn't really allocate memory (unless forced). it sets up that range of memory to demand fault in pages as they are touched
02:06:14 <doug16k> or even, only when they are written. it may map in a read only zero page and only commit an actual page on write
02:06:19 <bal_> it just allocates 4 bytes on the stack
02:06:28 <bal_> well, 8 bytes on x64
02:06:46 <doug16k> your example says "main". you think it jumps straight into main at startup? lots of stuff happens before main is called
02:06:55 <bal_> so if I just have "int main() { char *x; }" there is not write
02:07:23 <bal_> yes, but it is the same stuff for each run
02:09:56 <Mutabah> bal_: Modern OSes do "address space layout randomisation"
02:10:02 --- quit: quc (Remote host closed the connection)
02:10:04 <Mutabah> Which means that each run will have different addresses
02:10:15 --- join: quc (~quc@host-89-230-166-149.dynamic.mm.pl) joined #osdev
02:10:31 <bal_> right
02:10:48 <bal_> so ASLR also change how physical mem is mapped?
02:10:50 <doug16k> x64 has a redzone, it doesn't allocate anything on the stack
02:11:07 <bal_> doug16k: what?
02:11:18 <bal_> so x is not on the stack?
02:11:19 <doug16k> if you see a sub of rsp, it is simply realigning the stack pointer
02:11:25 <doug16k> probably not
02:11:29 <doug16k> there are lots of registers
02:11:48 <bal_> but stack is still used for local vars..
02:11:55 <doug16k> not necessarily
02:12:26 <doug16k> the compiler can rely on rbx, rbp, r12, r13, r14, r15 being preserved across calls (if there were even any calls)
02:12:39 <doug16k> your main can use all registers except rsp, 15 to choose from
02:12:44 <bal_> ok, I will use char x[256]; then
02:12:48 --- quit: lxpz (Read error: Connection reset by peer)
02:13:07 --- join: lxpz (~lxpz@shiki.adnab.me) joined #osdev
02:13:28 <doug16k> the compiler can see through BS. you need to either make it volatile or do something with it
02:14:37 <bal_> yeah
02:14:53 <bal_> anyway the point was: on a segfault the PF handler is called?
02:15:00 <rmf1723> As far as the compiler is concerned, `int main() { char *x; x[1] = 0; }` can simply be `int main() {}`.
02:15:02 <doug16k> other way around
02:16:16 <doug16k> page fault happens, OS determines whether it is expected or not. if not, it injects a signal into the process, the action of that signal determines what happens. unless you say otherwise what to do, it terminates the process
02:16:19 <gamozo> segfault is a concept that includes multiple exceptions
02:16:24 <gamozo> it's not directly mapped to a single exception
02:16:50 <bal_> there is a invalid access in a process (out of bound or something like that), CPU raises a fault because the address is not mapped or not accessible/permissions/etc. fault is handled by PF handler.. PF handler checks if it is a segfault or just need to map the right page. if it is a segfault call segfault handler, if it is defined, if not just abort the process
02:16:52 <bal_> right?
02:17:27 <doug16k> yes
02:17:34 <gamozo> invalid access is a page fault, general protection fault, or alignment fault
02:18:07 <gamozo> on 64-bit an invalid access that's non-canon (top 16 bits of teh address aren't sign extended) causes a #GP
02:18:12 <gamozo> it's stupid and annoying
02:18:24 <bal_> well, it is handled as sigbus, not segfault
02:18:45 <bal_> at least on linux
02:20:05 <gamozo> hmm? it should be a sigsegv
02:21:30 <doug16k> http://coliru.stacked-crooked.com/a/aca5c9f54a1d5d02 <-- sigsegv
02:21:30 <bslsk05> ​coliru.stacked-crooked.com: Coliru Viewer
02:21:54 <bal_> ah ok
02:22:10 <bal_> probably it was a different thing that generates sigbus
02:22:11 <gamozo> sigbus IIRC is alignment issues or file maps or something
02:22:32 <doug16k> if you access a file mapping beyond EOF, yeah, it is sigbus
02:25:01 <bal_> ok, so is there a reliable way to calculate PF count?
02:25:05 <doug16k> alignment check is sigbus -> http://coliru.stacked-crooked.com/a/21bb231b623ad7bc
02:25:05 <bslsk05> ​coliru.stacked-crooked.com: Coliru Viewer
02:25:34 <bal_> what is bts?
02:25:51 <doug16k> oops: http://coliru.stacked-crooked.com/a/c9bbaf75800f87ad
02:25:52 <gamozo> branch trace store?
02:25:52 <bslsk05> ​coliru.stacked-crooked.com: Coliru Viewer
02:25:55 <doug16k> bit test and set
02:25:59 <gamozo> oh
02:26:00 <gamozo> yeah
02:26:05 <bal_> ah
02:26:29 <bal_> so are you setting the bit 18 in temp var
02:26:47 <doug16k> that is the crap you have to do to set bit 18 of eflags yeah :)
02:27:05 <doug16k> that is the alignment check flag
02:27:07 <bal_> what is bit 18 in eflags?
02:27:10 <bal_> ah ok
02:27:12 <bal_> thanks
02:27:19 <doug16k> it raises an exception on misaligned memory access
02:27:27 <doug16k> if the kernel allowed it
02:28:28 <bal_> but why it is unaligned when you write to the first byte of buf?
02:29:08 <doug16k> buf is 32 bit aligned, I cast it to char, advance it one byte, and cast it back to int pointer, then write a 32 bit value there. that is a misaligned destination
02:29:44 <bal_> uhm
02:30:16 <bal_> but char* and int* are both 4 bytes
02:30:52 <doug16k> (char*)buf means, take buf (a pointer to the beginning of that buffer) and convert it to a char *...
02:31:08 <doug16k> then I add one, which calculates a pointer 1 byte after the start of buf...
02:31:22 <doug16k> then I cast that (now not 32 bit aligned) pointer back to an int pointer...
02:31:24 <bal_> ah the +1 here (char*)(buf + 1) is done before the (int*) cast
02:31:40 <doug16k> then I dereference that whole thing and write a 32 bit value to an address that is not 32 bit aligned
02:32:12 <doug16k> which would be fine - but I set AC in EFLAGS, so it has a fit, and raises an alignment check exception
02:32:17 <doug16k> kernel converts that to sigbus
02:37:04 --- quit: KidBeta (Read error: Connection reset by peer)
02:38:15 --- quit: Kimundi_ (Remote host closed the connection)
02:38:26 --- join: Kimundi_ (~Kimundi@dynip-129-217-119-172.wifi.tu-dortmund.de) joined #osdev
02:40:42 --- quit: xerpi_ (Quit: Leaving)
02:49:41 <doug16k> interesting: http://coliru.stacked-crooked.com/a/27dd35c897317b3d
02:49:42 <bslsk05> ​coliru.stacked-crooked.com: Coliru Viewer
02:50:55 <doug16k> why 4?
02:51:39 <bal_> it should be 2, right?
02:51:45 --- quit: Kimundi_ (Remote host closed the connection)
02:51:49 <doug16k> I was expecting 1
02:51:56 --- join: Kimundi_ (~Kimundi@dynip-129-217-119-172.wifi.tu-dortmund.de) joined #osdev
02:51:58 <bal_> ah no,
02:51:58 <bal_> 1
02:51:59 <bal_> yes
02:55:05 --- quit: caen23 (Quit: Lost terminal)
02:56:15 --- quit: Kimundi_ (Remote host closed the connection)
02:56:40 --- join: Kimundi_ (~Kimundi@dynip-129-217-119-172.wifi.tu-dortmund.de) joined #osdev
02:57:04 --- quit: Lowl3v3l (Remote host closed the connection)
03:00:45 --- join: Lowl3v3l (~Lowl3v3l@dslb-088-075-089-098.088.075.pools.vodafone-ip.de) joined #osdev
03:09:42 <Brnocrist> https://marc.info/?l=kvm&m=151543506500957&w=2
03:09:47 <bslsk05> ​marc.info: '[PATCH 0/7] KVM: x86: expose CVE-2017-5715 ("Spectre variant 2") mitigations to guest' - MARC
03:12:53 --- quit: Kimundi_ (Remote host closed the connection)
03:12:57 --- join: Kimundi__ (~Kimundi@dynip-129-217-119-172.wifi.tu-dortmund.de) joined #osdev
03:28:45 --- quit: Kimundi__ (Remote host closed the connection)
03:28:56 --- join: Kimundi__ (~Kimundi@dynip-129-217-119-172.wifi.tu-dortmund.de) joined #osdev
03:35:00 --- quit: elderK (Quit: Connection closed for inactivity)
03:42:50 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
03:44:45 --- quit: Kimundi__ (Read error: Connection reset by peer)
03:44:56 --- join: Kimundi__ (~Kimundi@dynip-129-217-119-172.wifi.tu-dortmund.de) joined #osdev
03:55:02 --- quit: gamozo (Ping timeout: 248 seconds)
03:57:10 --- quit: caen23 (Quit: Lost terminal)
03:57:21 --- join: gamozo (~pleb@96.74.23.209) joined #osdev
04:17:40 --- join: zng (~zng@ool-18ba49be.dyn.optonline.net) joined #osdev
04:17:50 --- quit: Belxjander (Ping timeout: 240 seconds)
04:20:24 --- join: m_t (~m_t@p57B3C3D1.dip0.t-ipconnect.de) joined #osdev
04:21:50 --- quit: daniele_athome (Ping timeout: 240 seconds)
04:22:39 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
04:25:08 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
04:26:51 --- quit: zng (Read error: Connection reset by peer)
04:27:20 --- join: zng (~zng@ool-18ba49be.dyn.optonline.net) joined #osdev
04:30:13 --- quit: Humble (Ping timeout: 255 seconds)
04:31:12 --- quit: darklink (Ping timeout: 256 seconds)
04:32:33 --- join: darklink (~darklink@unaffiliated/darklink) joined #osdev
04:34:35 --- join: uvgroovy (~uvgroovy@2601:184:4980:e75:6d8c:671b:a48a:2633) joined #osdev
04:40:44 --- join: vaibhav (~vnagare@125.16.97.124) joined #osdev
04:43:09 --- join: glauxosdever (~alex@athedsl-4445361.home.otenet.gr) joined #osdev
04:46:01 --- quit: awang_ (Quit: leaving)
04:46:48 --- quit: sdfgsdf (Ping timeout: 248 seconds)
04:47:54 --- quit: k4m1 (Quit: bbl)
04:49:44 --- join: Humble (~hchiramm@223.186.248.142) joined #osdev
04:53:06 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
04:55:42 --- quit: bal_ (Ping timeout: 260 seconds)
04:58:40 --- quit: awang (Ping timeout: 252 seconds)
05:01:21 --- nick: vaibhav -> vaibhav|afk
05:07:23 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
05:15:09 --- join: tavish (~tavish@unaffiliated/tavish) joined #osdev
05:19:41 --- join: awang (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
05:32:20 --- quit: Belxjander (Ping timeout: 268 seconds)
05:33:26 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
05:51:05 --- quit: daniele_athome (Ping timeout: 246 seconds)
05:51:34 --- nick: ZeDestructor -> Kalerath
05:51:47 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
06:07:21 --- quit: Humble (Read error: Connection reset by peer)
06:08:31 --- join: alphawarr1or (uid243905@gateway/web/irccloud.com/x-vlzzhrsdhahuatzv) joined #osdev
06:18:31 --- quit: m_t (Quit: Leaving)
06:20:29 --- quit: listenmore (Remote host closed the connection)
06:20:53 --- join: listenmore (~strike@2.27.123.231) joined #osdev
06:36:48 --- quit: Belxjander (Ping timeout: 260 seconds)
06:38:58 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
06:41:52 --- quit: uvgroovy (Ping timeout: 265 seconds)
06:44:27 --- join: mdunn (~Thunderbi@host86-139-25-98.range86-139.btcentralplus.com) joined #osdev
06:47:08 <graphitemaster> geist, hehe https://securityaffairs.co/wordpress/67498/hacking/microsoft-kb4056892-bricks-athlon-pcs.html
06:47:11 <bslsk05> ​securityaffairs.co: Microsoft KB4056892 Meltdown/Spectre patch bricks AMD Athlon-powered machinesSecurity Affairs
06:49:58 --- join: JusticeEX (~justiceex@pool-108-30-196-198.nycmny.fios.verizon.net) joined #osdev
06:50:12 --- quit: epony (Read error: Connection reset by peer)
06:50:59 --- join: epony (~nym@77-85-133-5.ip.btc-net.bg) joined #osdev
06:54:26 --- quit: epony (Client Quit)
06:56:46 --- join: uvgroovy (~uvgroovy@199.188.233.130) joined #osdev
06:56:46 --- quit: uvgroovy (Remote host closed the connection)
06:56:58 --- join: uvgroovy (~uvgroovy@199.188.233.130) joined #osdev
06:57:14 --- quit: uvgroovy (Client Quit)
06:58:16 --- quit: mdunn (Quit: mdunn)
07:00:03 <Brnocrist> http://www.ece.eng.wayne.edu/~sjiang/ECE7995-winter-09/lecture-7.pdf
07:01:37 --- join: mdunn (~Thunderbi@host86-139-25-98.range86-139.btcentralplus.com) joined #osdev
07:02:40 --- join: uvgroovy (~uvgroovy@199.188.233.130) joined #osdev
07:03:13 --- quit: mdunn (Client Quit)
07:03:21 <lava> https://twitter.com/mlqxyz/status/950744467736354816
07:03:21 <bslsk05> ​twitter: <mlqxyz> Releasing our PoC implementations for #Meltdown - https://github.com/iaik/meltdown - More to follow /cc @misc0110 @lavados @StefanMangard #intelbug #kaiser #kpti
07:05:34 --- quit: uvgroovy (Client Quit)
07:05:46 --- join: uvgroovy (~uvgroovy@199.188.233.130) joined #osdev
07:18:12 --- quit: listenmore (Remote host closed the connection)
07:18:37 --- join: listenmore (~strike@2.27.123.231) joined #osdev
07:24:50 --- quit: regreg_ (Ping timeout: 240 seconds)
07:29:05 --- quit: xenos1984 (Quit: Leaving.)
07:30:10 --- join: pictron (~tom@pool-173-79-33-247.washdc.fios.verizon.net) joined #osdev
07:33:19 --- join: Toldierone (root@toldiero.net) joined #osdev
07:33:40 --- join: sinetek_ (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
07:34:14 --- join: hmmmm (~sdfgsf@pool-72-79-169-212.sctnpa.east.verizon.net) joined #osdev
07:36:24 --- quit: uvgroovy (Ping timeout: 276 seconds)
07:39:54 --- quit: return0e (Ping timeout: 256 seconds)
07:41:08 --- join: regreg (~regreg@85.121.54.224) joined #osdev
07:42:19 --- join: Humble (~hchiramm@223.237.211.137) joined #osdev
07:43:43 --- join: kimundi (~Kimundi@dhl1116.cs.uni-dortmund.de) joined #osdev
07:45:38 --- quit: Kimundi__ (Ping timeout: 260 seconds)
07:51:19 --- join: return0e (~return0e@87-102-105-145.static.kcom.net.uk) joined #osdev
07:58:50 <MrOlsen> I can't stop, the way I feel
08:01:38 --- join: multi_io_ (~olaf@x4db34f2c.dyn.telefonica.de) joined #osdev
08:03:14 <MrOlsen> Can you hear me calling out your name? You know that I am falling and I don't know what to say.
08:03:30 <MrOlsen> Maybe no 70s/80s babies here
08:04:53 --- quit: multi_io (Ping timeout: 260 seconds)
08:05:46 --- join: eivarv (~eivarv@cm-84.215.4.97.getinternet.no) joined #osdev
08:08:05 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
08:08:59 --- quit: bm371613 (Quit: Konversation terminated!)
08:10:30 --- quit: nzoueidi (Ping timeout: 248 seconds)
08:10:42 --- part: rubenwardy left #osdev
08:11:11 --- join: mpascale00 (~mpascale@207.244.71.98) joined #osdev
08:13:38 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
08:19:06 --- quit: xenos1984 (Quit: Leaving.)
08:21:50 --- join: gdh (~gdh@2605:a601:639:2c00:70ad:592c:61b0:7501) joined #osdev
08:22:24 --- quit: sprocklem (Ping timeout: 256 seconds)
08:22:56 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
08:24:11 --- join: dennis95 (~dennis@p50915F41.dip0.t-ipconnect.de) joined #osdev
08:28:51 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
08:29:38 --- join: hmmmmm (~sdfgsf@pool-72-79-162-13.sctnpa.east.verizon.net) joined #osdev
08:30:09 <alphawarr1or> Fleetwood Mac - Everywhere?
08:30:29 --- join: Asu (~sdelang@AMarseille-658-1-170-61.w86-198.abo.wanadoo.fr) joined #osdev
08:32:27 --- quit: hmmmm (Ping timeout: 252 seconds)
08:35:45 --- quit: kimundi (Read error: Connection reset by peer)
08:37:00 --- join: kimundi (~Kimundi@dhl1116.cs.uni-dortmund.de) joined #osdev
08:38:50 <MrOlsen> ha!
08:39:00 <MrOlsen> how's it going alphawarrior
08:39:24 <MrOlsen> Cortana with the help of Spotiffy has been on an 80s kick this morning
08:40:51 <alphawarr1or> Well my brain capacity is of a sock's now I had lots of maths classes today... How about you?
08:41:15 <alphawarr1or> the 80s was a nice period in music I gotta agree
08:41:26 <alphawarr1or> does cortana learns what you like to listen too?
08:41:48 <MrOlsen> I'm enjoying the bit of sunlight today, the weather has been so crummy.
08:42:04 <MrOlsen> I'm not sure how she learns, I believe it could be based on the queries I present to her
08:42:37 <MrOlsen> But, Cortna is on invasion of privacy I don't mind.
08:43:28 --- nick: Kalerath -> ZeDestructor
08:44:45 <alphawarr1or> well yeah by using windows10 you basically agree that ms can collect anything they desire
08:45:00 <alphawarr1or> I've read it once
08:45:09 <alphawarr1or> oh well today here it was quite cloudy and warm
08:45:58 --- quit: Plazma (Quit: ZNC 1.6.5 - http://znc.in)
08:46:08 <MrOlsen> Where are you from?
08:51:09 <alphawarr1or> From the glorious country Hungary. How about you?
08:51:28 <fnodeuser> people are hungry there :P
08:51:48 --- join: Plazma (~Plazma@freenode/staff-emeritus/plazma) joined #osdev
08:52:46 <alphawarr1or> yeah as our money has a really low value :D
08:53:11 <fnodeuser> you have euro too :P
08:53:16 <MrOlsen> Me? From the great state of New York in the USA
08:53:18 <MrOlsen> lol
08:53:26 <alphawarr1or> nah we don't have euro
08:53:35 <alphawarr1or> we have our own currency
08:53:45 <rmf1723> Florins?
08:53:55 <alphawarr1or> HUF hungarian forints or just forint
08:54:02 <fnodeuser> i just saw that you don't
08:54:12 <fnodeuser> hm
08:54:30 <MrOlsen> that's interesting
08:54:32 <fnodeuser> damn, all this time i thought you had euro too
08:55:21 <alphawarr1or> well we sadly can't have euro
08:55:25 <fnodeuser> we have euro, but our economy is not 'booming'
08:55:39 <alphawarr1or> the average pay here is relatively low
08:55:41 <fnodeuser> why not?
08:56:32 <fnodeuser> Hungary joined the European Union in 2004 and has been part of the Schengen Area since 2007
08:56:37 <alphawarr1or> yup
08:56:40 <alphawarr1or> but our money is weak
08:56:57 <MrOlsen> weak like mouse
08:57:02 <rmf1723> IIRC Hungary is obliged to join the Eurozone *when* they meet the acceptance criteria, but I'm guessing they don't.
08:57:03 <fnodeuser> but strong like a cat :P
08:57:04 <alphawarr1or> 1 eur -> 309 huf
08:57:13 <MrOlsen> haah
08:57:41 <alphawarr1or> and average pays are well around the 500-600 eur
08:58:19 <rmf1723> alphawarr1or: that doesn't seem very different from Portugal.
08:58:44 <alphawarr1or> oh wow
08:58:52 <alphawarr1or> well things are kinda expensive here though
08:59:01 <alphawarr1or> I mean compared to other countries near us
08:59:03 <fnodeuser> https://en.wikipedia.org/wiki/Enlargement_of_the_eurozone#Hungary
08:59:04 <bslsk05> ​en.wikipedia.org: Enlargement of the eurozone - Wikipedia
08:59:21 <MrOlsen> brb must go check the mailbox
08:59:24 <alphawarr1or> like sometimes it's cheaper to go to Austria to buy stuff esp clothes as it's a lot cheaper and the quality is far better
08:59:55 <fnodeuser> that's something greeks do sometimes, going to bulgaria to buy some things cheaper
09:00:27 <fnodeuser> at least they did in the past, i don't know if that has changed the last few years
09:01:45 <alphawarr1or> oh I didn't know that
09:02:25 <fnodeuser> little-known facts :P
09:03:12 --- quit: kimundi (Ping timeout: 256 seconds)
09:18:34 <alphawarr1or> well yeah I guess mostly only people living that are would know these
09:19:18 --- quit: sinetek_ (Ping timeout: 248 seconds)
09:22:10 --- join: John___ (~John__@79.97.140.214) joined #osdev
09:29:14 --- join: raphaelsc (~utroz@191.249.184.239) joined #osdev
09:29:25 --- join: [Brain] (~brain@brainwave.brainbox.cc) joined #osdev
09:30:18 --- quit: m3nt4L (Remote host closed the connection)
09:32:26 --- join: sinetek_ (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
09:33:25 --- join: user10032 (~Thirteen@90.209.104.11) joined #osdev
09:41:49 --- join: kimundi (~Kimundi@p57A89A06.dip0.t-ipconnect.de) joined #osdev
09:43:13 --- join: Darmor (~Tom@198-91-187-5.cpe.distributel.net) joined #osdev
09:50:07 --- join: srjek (~srjek@2601:249:601:9e9d:898c:4669:40ef:3a4) joined #osdev
09:52:03 <kimundi> Where would I look up what the documented semantic of a given x86_64 assembler op is?
09:53:27 <Kazinsal> Volume 2 of the Intel software developer's manual
09:54:10 <kimundi> Thanks
10:00:02 --- quit: quc (Remote host closed the connection)
10:02:56 --- join: chjk6x_ (~chjk6x@105.158.101.254) joined #osdev
10:03:28 --- quit: oaken-source (Ping timeout: 240 seconds)
10:07:11 --- join: ox6 (836bae30@gateway/web/cgi-irc/kiwiirc.com/ip.131.107.174.48) joined #osdev
10:07:27 --- join: elderK (uid205007@pdpc/supporter/active/elderk) joined #osdev
10:10:14 --- join: epony (~nym@77-85-133-5.ip.btc-net.bg) joined #osdev
10:10:15 --- join: quc (~quc@host-89-230-166-149.dynamic.mm.pl) joined #osdev
10:11:27 --- quit: epony (Max SendQ exceeded)
10:12:17 --- join: epony (~nym@77-85-133-5.ip.btc-net.bg) joined #osdev
10:16:59 --- quit: ox6 (Changing host)
10:16:59 --- join: ox6 (836bae30@unaffiliated/ox6) joined #osdev
10:16:59 --- quit: ox6 (Changing host)
10:16:59 --- join: ox6 (836bae30@gateway/web/cgi-irc/kiwiirc.com/ip.131.107.174.48) joined #osdev
10:18:34 --- join: _aegis_ (~aegis@38.242.12.110) joined #osdev
10:31:02 --- quit: John___ (Ping timeout: 256 seconds)
10:34:30 --- join: caladrius (~quassel@188.25.93.211) joined #osdev
10:38:58 --- join: m_t (~m_t@p57B3C3D1.dip0.t-ipconnect.de) joined #osdev
10:40:43 --- join: John___ (~John__@79.97.140.214) joined #osdev
10:46:37 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
10:46:46 --- quit: bitch (Ping timeout: 248 seconds)
10:50:24 --- join: bitch (hctib@gateway/shell/elitebnc/x-jbpuelyoajondtxw) joined #osdev
10:50:24 --- quit: bitch (Changing host)
10:50:24 --- join: bitch (hctib@unaffiliated/bitch) joined #osdev
10:50:24 --- quit: bitch (Changing host)
10:50:24 --- join: bitch (hctib@gateway/shell/elitebnc/x-jbpuelyoajondtxw) joined #osdev
10:54:25 --- join: Arcaelyx (~Arcaelyx@2601:646:c200:27a1:50a:8361:2c7d:b24) joined #osdev
10:54:26 --- quit: ahrs (Read error: Connection reset by peer)
10:55:36 --- join: ahrs (quassel@gateway/vpn/privateinternetaccess/ahrs) joined #osdev
10:55:50 <geist> graphitemaster: ouch! wonder why
10:55:58 --- quit: vmlinuz (Ping timeout: 256 seconds)
10:56:36 <Brnocrist> lava, cool PoCs
10:56:57 <Brnocrist> I am reading the kvm one, it is amazing
10:57:04 --- quit: caladrius (Quit: shutdown -h now)
11:01:50 <lava> that one is from jann horn, not from our group ^^
11:02:25 <Brnocrist> oh yes, I know
11:02:39 <Brnocrist> I was talking about https://github.com/iaik/meltdown
11:02:40 <bslsk05> ​IAIK/meltdown - This repository contains several applications, demonstrating the Meltdown bug. (20 forks/324 watchers)
11:02:51 <graphitemaster> geist, turns out that on some Anthlon PCs that if you saturate speculative TLB reloads, it incorrectly interacts with RSM instruction and the CPU dead locks. It's a known errata actually. The solution is to clear CR0.PG before executing RSM (paging is enabled in SMM handler)
11:03:17 <graphitemaster> :D
11:03:54 <graphitemaster> but sadly the OS can't do that
11:04:04 <graphitemaster> needs to be microcode update
11:05:19 <Kazinsal> The Debian people are claiming AMD's microcode fix for Zen disables branch prediction.
11:05:37 <Kazinsal> I almost want to post to their mailing list asking if they think the cure for a broken foot is to amputate the leg at the hip
11:12:45 --- join: vmlinuz (~vmlinuz@32.104.18.202) joined #osdev
11:12:45 --- quit: vmlinuz (Changing host)
11:12:45 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
11:15:27 <pikhq> Kazinsal: As I understand it, that's just an incorrect description of it that made the rounds.
11:15:56 <pikhq> The microcode from what I saw, is similar to Intel's, in that it gives the ability to have some control over indirect branch prediction via some MSRs.
11:16:20 <Kazinsal> Oh, assuredly.
11:18:02 <pikhq> To be "fair", disabling branch prediction would certainly solve the problem.
11:18:41 <pikhq> Sure, you'd have a CPU that competed with cacheless 486s, but it wouldn't be vulnerable.
11:22:19 --- quit: ephemer0l (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
11:23:33 --- join: ephemer0l (~ephemer0l@pentoo/user/ephemer0l) joined #osdev
11:23:49 <Kazinsal> They can pry my 68030 from my cold dead hands!
11:24:19 <jjuran> :-D
11:24:42 <Kazinsal> Coworker is prototyping an Arduino-based IoT device in the lab
11:24:49 <Kazinsal> Not for corporate purposes
11:24:51 <Kazinsal> But uh
11:24:57 <Kazinsal> It's a smart carafe monitor.
11:25:09 <__pycache__> lol
11:25:19 <jjuran> An Internet carafe?
11:25:34 <Kazinsal> If you take the last of the coffee and don't brew a new pot, it blames you in the office-wide chat channel
11:25:45 <jjuran> haha
11:25:49 <__pycache__> amazing
11:25:56 <Kazinsal> We have been having a problem with last-cup bandits lately
11:26:09 <__pycache__> Kazinsal: where do you work exactly?
11:26:22 <__pycache__> sounds like a fun place
11:26:33 <__pycache__> my coworkers are boring buffoons
11:27:18 <Prf_Jakob> Kazinsal: 68030 has caches btw :p
11:27:35 <Kazinsal> A network hardware reseller/service provider in Canada who unfortunately shares a name with a terrible ISP in the US
11:27:46 <jjuran> Prf_Jakob: No branch prediction, though
11:28:13 <jjuran> Kazinsal: That could be any of them :-P
11:28:19 <Kazinsal> :D
11:28:28 <__pycache__> Kazinsal: too broad tp pinpoint
11:28:34 <Kazinsal> Back when I was on the NOC I used to get phone calls for that ISP all the time and had to explain, "no, no, we're in *Canada*"
11:28:41 <Kazinsal> __pycache__: :)
11:28:44 <Prf_Jakob> jjuran: I do wonder if it does speculative execution tho.
11:29:07 <__pycache__> lol
11:29:11 <Prf_Jakob> jjuran: mc68k addressing modes beggs for it.
11:29:15 <jjuran> No, at least through the 68040 they’re in-order.
11:29:25 <jjuran> To my knowledge
11:29:43 <jjuran> Prf_Jakob: Begs how?
11:29:51 <Kazinsal> Prf_Jakob: None of the 68ks do speculative execution, but the 68060 does have branch prediction and a dual pipeline
11:30:30 <Prf_Jakob> You can decode the source part of the instruction a head of time and issue the read moving the data to the cache.
11:30:41 <jjuran> My recollection is that awareness of pipelining in Mac assembly began with PowerPC.
11:30:44 <Prf_Jakob> In thoery, don't know how deep they go
11:31:07 <Kazinsal> Yep
11:31:24 <__pycache__> there's so many things i want to attempt just to fool around in my kernel but so little free time
11:31:28 <__pycache__> it drives me crazy
11:31:30 <Kazinsal> The 68060 was never used in any Apple products
11:31:38 <__pycache__> how do you peeps find time for your OS?
11:32:24 <Kazinsal> Honestly I haven't put any serious time into my OS in months :(
11:32:56 <Kazinsal> I started rewriting the build system the other day to try to double-clutch my brain
11:33:01 <Prf_Jakob> Kazinsal: I'm slowly doing a mc68k in fpga accelerator for Amiga.
11:33:18 <Prf_Jakob> Learning loads of new stuff along the way.
11:33:30 <__pycache__> i need to implement the PIC, then a PIT so i can do a cool animated logo :P
11:33:42 <jjuran> Prf_Jakob: Oh, neat. I’m developing a software m68k emulator.
11:33:44 <__pycache__> then I need to implement a PM I guess
11:33:47 <__pycache__> PMM*
11:34:05 <__pycache__> then the VMM/mapper, then scheduling and threads and all that jazz
11:34:13 <Prf_Jakob> jjuran: Cool, WinAUE should be a good place to look at.
11:34:25 <Kazinsal> Prf_Jakob: Rad. '040?
11:34:31 <jjuran> I wrote my own core. :-)
11:34:34 <Prf_Jakob> I think they mapped out all of the instructions
11:35:09 <Prf_Jakob> Kazinsal: Probably '020', MIST has a 020ish core that I thinking of stealing.
11:35:47 <Prf_Jakob> Kazinsal: I would like to go up to '030' but that is so far out I'm not concidering it.
11:36:24 <Kazinsal> Yeah, the added on-chip MMU throws a wrench in
11:36:59 <Prf_Jakob> Right
11:37:40 <Prf_Jakob> My idea was to have hidden caches, so anything reading from ram above 16MB would get cached because no other hardware can read that anyways.
11:38:00 <Prf_Jakob> At least for A2000 and below.
11:38:02 --- join: grange_c (~grange_c@LFbn-1-9850-230.w86-202.abo.wanadoo.fr) joined #osdev
11:38:05 <grange_c> Hello!
11:38:19 <Kazinsal> Howdy
11:38:21 <geist> a haw haw haw
11:38:28 <__pycache__> h
11:38:58 <Kazinsal> FUCK. I can't get this parallel Make issue to reproduce. Goddammit, I must have some kind of synchronization issue.
11:39:35 <geist> what OS are you running on?
11:39:52 <Kazinsal> Ubuntu in latest WSL
11:39:53 --- quit: caen23 (Quit: Lost terminal)
11:40:07 <Kazinsal> I have exactly once gotten NASM to spaz and fail in the -O2 stage, and I don't know how.
11:40:19 <geist> yeah was gonna ask about that. I'm starting to think there's some sort of racy stff with file access in WSL
11:40:29 <geist> i've seen some sort of weird file race condition stuff inside our fuchsia builds on it too
11:40:41 <Kazinsal> I think it might have been trying to read in a blob *while* another NASM instance was assembling that blob
11:40:52 <geist> like 'i tried to move this file but it's not there and i had just put it there' in some fairly multithreaded Go tool
11:41:18 <geist> which when you think about it, posix has fairly strict semantics about. if the WSL layer has some sort of delayed something in there it might occasionally show up
11:41:47 <Kazinsal> Hell with it, those blobs aren't depended upon for anything other than final linking, I'm moving those to the single-threaded stage
11:41:50 <geist> specifically atomicity of file modifications between threads/processes
11:42:15 <Kazinsal> Yeah I think Windows has always been a little more loose with multithreaded file semantics
11:43:32 <geist> i could, for example, see it not be as strict about 'written data to a file appears to be fully present at the end of a write() call via external observers in another file handle'
11:44:01 <geist> so if you had some code path that writes a file but hasn't closed it and another process opens it and expects to read the bits
11:44:10 <geist> may be that until you close it it doesn't sync, or something
11:44:50 <geist> if there's any sort of caching done at the file handle. fundamentally windows FS layer isn't really vnode based, so it may end up doing something like that
11:44:54 <Kazinsal> That seems like it might have been the problem. NASM's optimizer allows for ten passes before stalling out, so if it had to spend an extra pass every time the blob being %incbin'd was changed, it could run out of passes pretty quickly
11:46:33 <geist> or, for example, the teardown of a process may be asynchronous. cold be the process exits and then some worker thread starts tearing it down
11:46:46 <geist> an the file handle doesn't get closed until potentially some time later. that would be a very windowsy way of doing things
11:51:41 --- quit: vmlinuz (Ping timeout: 265 seconds)
11:56:37 --- join: vmlinuz (~vmlinuz@32.104.18.203) joined #osdev
11:56:37 --- quit: vmlinuz (Changing host)
11:56:37 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
11:56:50 --- quit: sprocklem (Ping timeout: 240 seconds)
11:57:28 <Kazinsal> Anyone have handy access to a macOS box? I'm wondering if sysctl -n hw.ncpu returns the right number of logical processors
11:58:21 --- quit: vmlinuz (Remote host closed the connection)
12:08:30 --- join: Pyjong (~pi@14-232-24-185.static.servebyte.com) joined #osdev
12:10:07 <Kazinsal> Hrm. Getting a sane logical processor count out of all of the unices is actually kind of a pain.
12:10:12 <Kazinsal> Maybe I'll just default to four threads
12:10:37 <geist> hang on
12:10:50 <geist> seems to report all hw threads
12:10:56 <geist> ie, 4 on a dual core HT box
12:11:45 <Kazinsal> Hmm, okay.
12:11:50 <meowrobot> 8 on a quad-core HT imac here
12:11:56 <Kazinsal> Rad.
12:12:10 <Kazinsal> hw.ncpu doesn't seem to exist on WSL, grumble grumble
12:12:15 <geist> i've been using that sysctl for years to get the thread count. iirc it works the same way on all BSDs
12:12:18 <geist> so its' safe to use it
12:12:26 <geist> yah i think it's a BSD thing
12:16:31 --- quit: m_t (Quit: Leaving)
12:18:34 <Pyjong> Today I learned hacking means "to use something in a different way than it was designed for".. I always thought it just means to break computer security :O
12:19:44 <fnodeuser> hacking != cracking
12:20:46 <Kazinsal> DAMMIT SOMEONE DIDN'T REFILL THE COFFEE POT
12:21:03 <geist> wait i thought the alarm was supposed to go off?
12:21:22 <geist> you should throw a tantrum, throw the pot on the floor, shatter it
12:21:23 <Kazinsal> Still prototyping it :(
12:21:36 <ox6> cpuid?
12:22:00 * geist serializes
12:22:25 <Kazinsal> Apparently we got OK to prototype this because someone last-cup bandited the company president
12:22:26 --- join: bm371613 (~bartek@89-64-31-161.dynamic.chello.pl) joined #osdev
12:22:31 <Kazinsal> Magical
12:26:28 <immibis> hence the term "life hacks"
12:28:20 <geist> time to switch to everyone makes their own goddamn coffee
12:31:15 <Kazinsal> We're trying to break into the IoT space (god help us all) so I guess someone spun this as a potential venture of some kind
12:31:29 <Kazinsal> I work for an odd company
12:36:27 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
12:38:37 --- quit: gdh (Quit: Leaving)
12:41:58 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
12:42:04 <Lowl3v3l> Kazinsal: meanwhile, i am working for the german state on a project so evilly fucked up, i require new words to even describe the fuckery. :D We are all so fucking doomed
12:42:05 --- join: rubenwardy (~rubenward@unaffiliated/rubenwardy) joined #osdev
12:42:31 <Kazinsal> Pssst. Tell them to stop threatening to decommission perfectly good nuclear power plants
12:43:15 <Lowl3v3l> Kazinsal: not working on powerplants, but i have the slight fear, that those things are programmed in the same way and that if i ever verified they are i'd stop sleeping xD
12:43:32 <ox6> windows iot?
12:44:17 <Lowl3v3l> Kazinsal: its like.... i saw this mess and my first guess was that rewriting it in C, from scratch, without any libraries wouldn't only lead to a better product, but it would also be faster than even trying to understand or fix this clusterfuck of cosmological scale
12:44:28 <Kazinsal> I don't think I want to know more
12:44:30 <Lowl3v3l> ox6: something along those lines
12:45:22 <ox6> if i never see another ble stack it will be too soon
12:45:45 <Lowl3v3l> Kazinsal: i mean, the german state can't even get software for nothing but a more glorified electronical library right. I can only fathom how powerplants or hospitals look IT wise
12:47:59 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
12:50:28 <lava> Brnocrist: well then, thanks ^^
12:53:02 <ox6> SCADA is big business, i don't think i have ever seen anyone roll anything in-house
12:53:07 <ox6> big price tag tho
12:54:02 <mavhq> The government invented computer games to distract us from the incredibly easy to hack real world
12:56:12 <geist> actually it's the alliance that invented it to find starfighters to defeat the Kodan Armada
12:56:29 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
12:56:49 --- join: silas (~silas@177.104.48.3) joined #osdev
12:57:28 --- quit: eivarv (Quit: Sleep)
12:57:56 --- quit: tavish (Quit: Leaving)
12:57:58 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
12:59:29 --- quit: regreg (Ping timeout: 246 seconds)
13:03:17 <sortie> Evening
13:06:19 <rain1> hey sortie :)
13:06:45 <sortie> Yo rain1
13:07:17 <sortie> I had my evening coffee
13:07:28 <sortie> Shitposting on twitter then I shall commence some quality osdev
13:07:28 <rain1> love a good coffee
13:10:17 <rain1> sortie your OS is compatable with linux syscalls right?
13:10:31 <sortie> I implement my own syscall ABI
13:10:36 <rain1> oh!
13:10:38 <sortie> I implement a lot of POSIX though
13:10:49 <rain1> do you change 'fork' in any way?
13:10:51 <sortie> So I am largely API compatible, but not ABI compatible
13:10:59 <rain1> I see!
13:11:28 <sortie> rain1: I have fork(2) as well, yes, and it works the same way, though it's implemented by a call to my sfork(2) which calls tfork(2) -- roughly Linux clone(2) but better
13:12:27 --- quit: chjk6x_ (Ping timeout: 276 seconds)
13:14:03 --- quit: bm371613 (Quit: Konversation terminated!)
13:14:23 --- quit: Pyjong (Quit: TinyIRC 1.1)
13:16:56 --- join: tacco\unfoog (~tacco@dslb-178-007-244-013.178.007.pools.vodafone-ip.de) joined #osdev
13:17:31 <sortie> rain1: I'm working on my os-test tonight. I've discovered that I can just write a lot of unit tests for obscure parts of the kernel interface, run them on VMs of every free Unix-like, and then just find bugs and interesting differences.
13:17:45 <sortie> Sweet old UDP turns out to be much more surprising that I expected
13:17:49 --- join: Matrice64 (~Matrice64@209.248.237.210.nw.nuvox.net) joined #osdev
13:18:08 <rain1> i like the sound of that! maybe you'll find some really interesting things
13:18:35 <sortie> https://sortix.org/os-test/
13:18:36 <bslsk05> ​sortix.org: os-test
13:18:43 <sortie> Yeah I did IMO
13:19:01 <sortie> Mostly I found a lot of stuff and it's hard to figure out what's actually supposed to happen when so many systems don't agree
13:21:45 <retpoline> i still firmly belive that 2018 is the year of the Sortix desktop :)
13:22:07 <sortie> I love that username
13:22:12 <radens> ^^
13:22:22 <geist> haha
13:22:32 <retpoline> :D
13:22:37 <geist> kinda makes you want to jump on them
13:22:53 <sortie> retpoline: Better /msg nickserv group retpoline if you already have a nickserv account to add it to your account
13:23:00 <Kazinsal> Windows Subsystem for Sortix
13:23:22 <sortie> retpoline: Actually, 2017 was the year of the Sortix desktop. I'm pretty sure this is the year of the Sortix network.
13:23:24 <radens> Sortix Subsystem for Windowa
13:23:26 <retpoline> sortie: ty, did so
13:23:53 <Kazinsal> Hmm. Sortix network, routed by Araxes
13:23:55 --- join: chjk6x_ (~chjk6x@105.158.101.254) joined #osdev
13:24:00 <Kazinsal> Iiiiiiiit's co-op time!
13:24:11 <sortie> retpoline: :)
13:24:38 <sortie> Kazinsal: I do want to build a Sortix router at one point, but still some way to go ;)
13:24:52 <sortie> RFC compliant routing is tricky.
13:24:53 <retpoline> sortie, also, any plans for sortcoin? :P
13:25:33 <sortie> retpoline: I've made people install Sortix now for years and no one investigated why it uses 100% CPU always
13:25:35 <Kazinsal> Basic routing is straightforward. RFC 1542 compliance is more of a layer encapsulation problem than anything else
13:25:49 <Kazinsal> It's like NAT for UDP broadcasts
13:25:59 <retpoline> sortie: that sounds like a very good plan tbh :)
13:27:25 <sortie> Kazinsal: You say that but then one reads RFC 1009 et al
13:27:50 --- quit: Lucretia (Remote host closed the connection)
13:28:09 <sortie> Strangely noone has ported bitcoin to Sortix
13:28:52 <Kazinsal> Good news is 1009 is obsoleted
13:28:58 --- quit: chjk6x_ (Ping timeout: 256 seconds)
13:29:05 <Kazinsal> Bad news is it's obsoleted by 1812, which is still 23 years old
13:29:26 <Kazinsal> A lot of 1812 is for routing between disparate link layers
13:29:58 <sortie> Kazinsal: Oh yeah all these RFCs are obsolete
13:30:17 <Kazinsal> If you've got like, an ATM or Frame Relay card and you want to route on that, then yeah, RFC 1812 is something to pay attention to
13:30:21 <sortie> Kazinsal: But I mostly start from the oldest one (unless it has been wholly replaced, which rarely happens) and work my way up from that
13:30:30 <sortie> Who has the time to read all the TCP extensions :)
13:30:51 <sortie> Kazinsal: At least I document which RFCs I have read & implemented
13:31:19 <Kazinsal> Any RFC that says "Historic" at the top you can ignore :)
13:32:08 <sortie> Yeah I know
13:32:22 <sortie> Kazinsal: Well, sometimes they are superseeded but by a set of documents that are hard to read
13:32:24 <sortie> https://users-cs.au.dk/~sortie/sortix/release/volatile/man/man4/ip.4.html#standards
13:32:25 <bslsk05> ​users-cs.au.dk: ip(4)
13:32:41 --- nick: vaibhav|afk -> vaibhav
13:32:46 --- quit: vaibhav (Quit: Leaving)
13:32:48 * sortie thinks he can make the best documented network stack, even if incomplete, at least the documentation describes the implementation
13:33:02 <Kazinsal> Yep, documentation is important.
13:33:09 <Kazinsal> That's why I'm writing a book to go with my styem
13:33:11 <Kazinsal> system*
13:33:15 <sortie> Cool!
13:33:17 <Kazinsal> Complete left-hand failure there
13:37:20 --- join: xerpi (~xerpi@67.red-88-23-239.staticip.rima-tde.net) joined #osdev
13:37:59 <Lowl3v3l> sortie: no doubt there. I suppose there's not a single one out there qualifying as "good" in any way xD
13:38:21 --- quit: xerpi (Remote host closed the connection)
13:38:42 --- join: xerpi (~xerpi@67.red-88-23-239.staticip.rima-tde.net) joined #osdev
13:39:20 <sortie> With the amount of compatibility testing I'm doing for the UDP stack, I'm almost tempted to bug bounty any corrections
13:40:37 --- join: d0w_ (4dac8cd3@gateway/web/freenode/ip.77.172.140.211) joined #osdev
13:40:38 <d0w_> hello
13:40:46 <Lowl3v3l> sortie: if i thought i was goodenough i'd look for errors. But networking is still a big blackbox to me and i have some kind of existential-programmer-crisis atm :D
13:40:52 --- quit: glauxosdever (Quit: leaving)
13:41:21 <Kazinsal> existential-programmer-crisis(8)
13:41:50 <d0w_> in the linux memory management doc I read: ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory , what does all phys memory mean in this context? doesn't user space pages mapped above that address?
13:41:59 <Lowl3v3l> Kazinsal: stepwise realisation just how fucked up everything is to the point where you dont trust anything xD
13:42:15 <geist> d0w_: means it maps say physical address 0 to 0xffff.....
13:42:29 <geist> and then a large run of physical memory, say 128GB or so
13:42:43 --- quit: user10032 (Quit: Leaving)
13:42:45 <geist> that way the kernel can easily access any piece of physical memory it wants by just adding that kernel address to it
13:43:00 <d0w_> ah ok
13:43:41 <d0w_> so the physical mem mapped between 0000000000000000 - 00007fffffffffff is virtually lower than PAGE_OFFSET, but is physically higher?
13:43:54 <sortie> Lowl3v3l: Kazinsal is right. Read the fine manual on how to program. May I recommend Brooks's classic and other goodies?
13:44:02 <geist> not sure what those #defines are, so i can't answer you
13:44:47 <d0w_> I mean as physcal addresses mapped in this virtual range is higher than phys kernel addresses
13:45:01 <Kazinsal> adding organizational overhead to a project makes it later; adding government overhead to a project makes it a prime opportunity for excessive contracting rates
13:46:08 --- quit: sprocklem (Ping timeout: 260 seconds)
13:46:27 --- quit: tomaw (Read error: Connection reset by peer)
13:46:44 --- quit: ohnx (Ping timeout: 246 seconds)
13:46:45 <d0w_> geist: is PAGE_OFFSET fixed also with KASLR?
13:46:58 --- join: tomaw (tom@freenode/staff/tomaw) joined #osdev
13:47:04 <geist> i have no idea what PAGE_OFFSET is, so i can't answer
13:47:26 <Lowl3v3l> sortie: i am always open to good programming resources ^^
13:47:40 <Lowl3v3l> though i dont think there are many better than SICP
13:48:01 <d0w_> geist: page offset is 0xffff880000000000
13:48:09 <geist> okay. so what *is* it?
13:48:11 <geist> what does it mean?
13:48:35 <d0w_> as far I understand it is the virtual address where kernel space starts
13:48:40 <geist> okay
13:48:45 --- join: sdfgsdf (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
13:48:50 <geist> so anyway, being that i dont hack on linux i can't answer your question
13:48:53 <rmf1723> No
13:49:06 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
13:49:06 <d0w_> no problem :)
13:49:08 <rmf1723> It's where the kernel maps all of physical memory
13:49:33 <d0w_> rmf1723: so also itself, right?
13:49:36 <rmf1723> That offset varies with KASLR
13:49:38 <geist> sounds to me that instead of just naming it what it is, someone was clever and pointed out that it's functionally a delta of physical address 0 to kernel address
13:49:57 <geist> vs naming it somehtin glike 'PHYSICAL_MAP_BASE, PHYSICAL_MAP_LEN' or whatnot
13:50:06 <geist> that sounds like typical linux
13:50:06 --- quit: grumble (Killed (Sigyn (BANG!)))
13:50:24 --- quit: John___ (Read error: Connection reset by peer)
13:50:32 <rmf1723> d0w_: incidentally. But it maps everything else as well.
13:50:42 --- join: grumble (~grumble@freenode/staff/grumble) joined #osdev
13:50:42 <geist> so i'm guessing you take physical address + PAGE_OFFSET and that gets you the physical mapping in kernel space
13:50:57 <rmf1723> geist: exactly
13:50:58 <d0w_> geist: http://elixir.free-electrons.com/linux/v4.4/source/arch/x86/include/asm/page_64_types.h#L35
13:50:59 --- join: oaken-source (~oaken-sou@p3E9D257C.dip0.t-ipconnect.de) joined #osdev
13:51:00 <bslsk05> ​elixir.free-electrons.com: linux/arch/x86/include/asm/page_64_types.h - Elixir - Free Electrons
13:51:32 <geist> anyway, yes that probably movees with KASLR too, though iirc there are only so many bits of entropy there. i remember reading some KASLR attack paper recently and i think there are only like 128 different possible slots for it
13:51:43 <geist> given the size of the mapping and the number of available virtual bits in kernel space
13:52:02 <geist> so it's fairly easy to attack and figure out where it is with spectre and whatnot
13:52:29 <rmf1723> geist: meltdown is enough
13:52:42 <geist> right
13:53:06 <geist> though it helps to know where it is currently mapped in kernel space, but that's pretty easy to figure out already with spectre style attacks
13:54:07 <rmf1723> https://github.com/IAIK/meltdown/blob/master/kaslr.c
13:54:09 <bslsk05> ​github.com: meltdown/kaslr.c at master · IAIK/meltdown · GitHub
13:54:24 <rmf1723> Here's an attack that finds the physical map offset
13:54:35 --- join: ohnx (~ohnx@unaffiliated/ohnx) joined #osdev
13:59:33 --- quit: ohnx (Ping timeout: 255 seconds)
13:59:48 --- join: chjk6x_ (~chjk6x@105.158.101.254) joined #osdev
13:59:52 --- join: svk (~svk@p2003006A6515B500A43A1775AD81DB5A.dip0.t-ipconnect.de) joined #osdev
14:00:00 --- quit: Darmor (Quit: Leaving)
14:01:26 <d0w_> rmf1723: so I am a little bit confused, user space is mapped between 0000000000000000 - 00007fffffffffff and all phys address are mapped between ffff880000000000 - ffffc7ffffffffff how user space use phys addresses?
14:02:03 --- join: John___ (~John__@79.97.140.214) joined #osdev
14:03:07 <rmf1723> It doesn't, not without something like Meltdown
14:03:34 <d0w_> no, wait, I am not talking about meltdown, but how this mapping works
14:03:57 <rmf1723> User space doesn't have any access to physical memory
14:04:19 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
14:04:20 --- join: ohnx (~ohnx@unaffiliated/ohnx) joined #osdev
14:04:52 <rain1> physical memory is allocated for a userspace program, then the userspace program access it through its own page tables
14:05:06 <d0w_> ok, but let's say a process uses address 0x1234 which is in userspace range, and has a physical address 0x5678, this phys address is mapped between virtual range ffff880000000000 - ffffc7ffffffffff ?
14:05:12 <rain1> so the address that look like 07ffffff get turned into physicall addresses
14:05:36 <rain1> but inside the kernel the ff880000-fffc7ffff stuff is like another way to look at the physical memory
14:06:11 <d0w_> ah, so the same process address has a different virt address in kernel space?
14:06:46 --- quit: daniele_athome (Ping timeout: 248 seconds)
14:07:01 --- quit: oaken-source (Ping timeout: 265 seconds)
14:07:38 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
14:08:24 <d0w_> maybe I was not clear, let me rephrase. if all physical space is mapped at virtual address range ffff880000000000 - ffffc7ffffffffff , how an user space address is translated to physical address if its virtual address is between 0 and 00007fffffffffff
14:10:23 <doug16k> the same physical memory can be mapped to multiple virtual addresses
14:10:25 --- quit: Matrice64 (Quit: lost in the ether)
14:10:47 <doug16k> the user memory is at the normal virtual address, and the physical memory behind it happens to also be in the physical mapping
14:11:43 <d0w_> so physical map is just a way that the kernel uses to have a 1:1 physical space mapping?
14:11:56 <doug16k> yes
14:12:43 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
14:13:02 <doug16k> it's just an optimization. in my kernel, I don't do a physical mapping. when I need that for drivers or whatever, I explicitly map the physical memory I need to an assigned virtual address
14:13:38 <d0w_> so a process virtual address like: 0x1234 (a valid address between 0 and 00007fffffffffff) has a different mapping in the kernel space (in the range ffff880000000000 - ffffc7ffffffffff)?
14:14:02 <doug16k> I don't feel comfortable having all memory completely unprotected there, a bad pointer can easily trash random things and cause very hard to find bugs
14:15:44 <doug16k> don't think of it as mutually exclusive. think of it as all physical memory is _also_ reachable in the physical mapping
14:16:14 <d0w_> ok
14:16:19 <doug16k> when that process is the current process, the kernel can reach user mode memory at the normal user visible address
14:16:31 <d0w_> so this map is just used to address physical space in the kernel
14:16:39 <doug16k> yes
14:17:19 <d0w_> everything in linux is overcomplicated
14:17:34 <doug16k> this is the usual way of doing it. it is not necessarily the case. in linux they have that physical mapping and can reach user memory
14:17:53 <Lowl3v3l> d0w_: "everything" ? nah. Many parts of linux are pretty solid and well engineered ;)
14:19:11 <rain1> it was a big surprise to me that the kernel was mapped into userspace programs - just with read and write permission disabled
14:20:01 <d0w_> for performance purpose I think
14:20:05 <rain1> yeah
14:20:56 <d0w_> so a context switch doesn't flush the TLB
14:21:12 <doug16k> some of it must be. where do you expect interrupts to go?
14:21:22 <rain1> I wonder how paging across different cores work
14:21:26 <rain1> could the kernel be placed in its own core?
14:21:38 <d0w_> no
14:21:41 <rain1> ah
14:21:48 <d0w_> each core has its own cr3
14:22:16 --- join: king_idiot (~ahaslett@124.157.115.222) joined #osdev
14:22:44 <d0w_> I don't know how same process switches the core during execution
14:22:49 <doug16k> each core has its own cr3 and its own TLB. usually they share the same page tables, but that's not necessary. you could have per-core page tables. that is how it can run two different processes at the same time in different cores
14:23:11 <rain1> wait if you have a separate cr3 for each core wouldn't that be perfect?
14:23:23 <doug16k> perfect for what?
14:23:31 <rain1> separateing the kernel from userspace
14:23:53 <doug16k> the computer (usually) spends almost all of its time in userspace. that would be a waste
14:23:59 <d0w_> if you want to run kernel on a dedicated core, yes.. but it doesn't
14:24:00 <doug16k> syscall overhead would be extremely high
14:24:25 <rain1> ah.. waste a core sure, but I was hoping it would have low syscall overhead
14:25:02 <doug16k> how would the kernel core mind-read that you did a syscall in the other core? it wouldn't. you would need some kind of shared memory thing or interprocessor interrupt
14:25:12 <d0w_> CPU is able to run 2 different syscall on different core at same time?
14:25:26 <doug16k> the calling thread would have to suspend until the kernel finished, then do more shared memory or interrupt traffic to resume it
14:25:44 <doug16k> yes
14:25:47 <d0w_> ok, so one syscall at time
14:26:14 <rain1> hmmm
14:26:24 <rain1> i see why the overhead is very high now
14:26:32 --- join: gdh (~gdh@2605:a601:639:2c00:70ad:592c:61b0:7501) joined #osdev
14:27:16 --- join: mmu_man (~revol@vaf26-2-82-244-111-82.fbx.proxad.net) joined #osdev
14:28:09 <radens> d0w_: actually I think there are strange numa kernels where one core has a kernel server, and the other cores send inter-processor interrupts to it. It's not a popular design for good reason though.
14:29:22 <d0w_> well, if it is not possible to run multiple syscall at same time on different core, it makes sense
14:30:42 <doug16k> it's feasible, sure. if every syscall was extremely asynchronous and the caller doesn't get a return value immediately, and there is enough work for that to be reasonable, and you don't mind cache-coherency overhead hammering lines back and forth, it is possible
14:32:23 <ox6> i usually see it on systems with no user/kernel mode disticntion
14:32:47 <ox6> at a general purpose computing scale the overhead will be way too high
14:33:16 <d0w_> doug16k: I mean different syscall from different process running on different core
14:33:40 <d0w_> so the syscall return value are independent for process
14:34:39 --- quit: ohnx (Ping timeout: 255 seconds)
14:36:19 <rain1> i like the idea of async syscalls
14:38:06 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
14:39:03 --- join: ohnx (~ohnx@unaffiliated/ohnx) joined #osdev
14:39:28 --- quit: freakazoid0223 (Ping timeout: 240 seconds)
14:41:33 --- quit: NotSecwitter (Ping timeout: 260 seconds)
14:42:37 <olsner> I wonder if Nix is a good approach to wrangling cross toolchains and such
14:44:01 <Lowl3v3l> olsner: its not that bad ( though my favorite way would be ridding us of them entirely to be honest :P)
14:49:18 <Kazinsal> I found a bug in PDF handling on my Kindle https://i.imgur.com/vljMqsn.jpg
14:49:28 <Kazinsal> Notice the occasional missing letter.
14:51:10 <Kazinsal> (The previous page was worse -- for example, "Trans end nt al Fun tions Pa kage")
14:58:04 --- quit: dennis95 (Quit: Leaving)
14:58:11 --- quit: alphawarr1or (Quit: Connection closed for inactivity)
14:58:30 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
15:00:25 --- quit: ahrs (Remote host closed the connection)
15:05:10 --- join: ahrs (quassel@gateway/vpn/privateinternetaccess/ahrs) joined #osdev
15:05:15 --- quit: d0w_ (Quit: Page closed)
15:19:18 --- quit: Asu (Ping timeout: 248 seconds)
15:23:45 --- quit: Humble (Ping timeout: 276 seconds)
15:27:39 <doug16k> Kazinsal, did you see if it behaves correctly in other viewers? could have been a bad converter
15:27:39 --- quit: sortie (Quit: Leaving)
15:28:03 <Kazinsal> Yeah, works fine in Chrome PDF, Firefox PDF, and Acrobat DC
15:32:31 --- quit: xenos1984 (Quit: Leaving.)
15:32:54 --- quit: ohnx (Ping timeout: 240 seconds)
15:33:22 --- quit: Shamar (Quit: leaving)
15:33:59 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
15:33:59 --- quit: Shamar (Client Quit)
15:36:17 --- quit: JusticeEX (Ping timeout: 246 seconds)
15:36:48 --- join: ohnx (~ohnx@unaffiliated/ohnx) joined #osdev
15:37:57 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
15:39:18 --- quit: svk (Quit: Leaving)
15:44:44 --- quit: xerpi (Quit: Leaving)
15:52:35 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
15:53:50 --- quit: ohnx (Ping timeout: 265 seconds)
15:55:26 --- join: JusticeEX (~justiceex@pool-108-30-196-198.nycmny.fios.verizon.net) joined #osdev
15:57:50 --- join: ohnx (~ohnx@unaffiliated/ohnx) joined #osdev
15:58:39 --- join: hppavilion[1] (~dosgmowdo@58-0-174-206.gci.net) joined #osdev
16:06:08 --- join: strike_ (~strike@2.27.123.231) joined #osdev
16:07:50 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
16:07:51 --- quit: listenmore (Ping timeout: 265 seconds)
16:08:20 --- quit: chjk6x_ (Ping timeout: 240 seconds)
16:09:23 --- quit: jeaye (Quit: WeeChat 1.9.1)
16:09:40 --- quit: ohnx (Ping timeout: 252 seconds)
16:10:47 --- join: jeaye (~jeaye@unaffiliated/jeaye) joined #osdev
16:21:23 --- join: ohnx (~ohnx@unaffiliated/ohnx) joined #osdev
16:23:11 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
16:24:54 --- quit: awang (Ping timeout: 255 seconds)
16:27:55 --- quit: Shamar (Quit: leaving)
16:29:43 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:30:05 --- quit: Belxjander (Ping timeout: 265 seconds)
16:32:03 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
16:34:57 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
16:35:55 --- quit: huaw (Ping timeout: 276 seconds)
16:36:34 --- quit: lutoma (Ping timeout: 276 seconds)
16:37:46 --- quit: epony (Remote host closed the connection)
16:39:18 <gamozo> one day i dream that all PXE roms will behave even remotely the same
16:40:09 --- join: lutoma (~lutoma@wikipedia/lutoma) joined #osdev
16:41:13 --- join: huaw (xexexepi@gateway/shell/elitebnc/x-wpntwhdogqgiyunf) joined #osdev
16:44:51 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
16:46:16 --- quit: sinetek_ (Quit: This computer has gone to sleep)
16:50:20 --- quit: kimundi (Ping timeout: 240 seconds)
16:50:51 --- quit: lutoma (Ping timeout: 276 seconds)
16:51:16 --- join: lutoma (~lutoma@wikipedia/lutoma) joined #osdev
16:52:07 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
16:55:51 --- join: epony (~nym@77-85-133-5.ip.btc-net.bg) joined #osdev
16:57:07 --- quit: epony (Max SendQ exceeded)
16:57:09 --- quit: elderK (Quit: Connection closed for inactivity)
16:57:55 --- join: epony (~nym@77-85-133-5.ip.btc-net.bg) joined #osdev
17:01:28 --- quit: awang (Ping timeout: 256 seconds)
17:03:57 --- quit: John___ (Read error: Connection reset by peer)
17:06:24 --- join: gianluca (~user@lugbari/people/gianluca) joined #osdev
17:07:17 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
17:07:53 <doug16k> gamozo, what behaves unexpectedly? eventually I'll be adding PXE
17:07:56 --- quit: mmu_man (Ping timeout: 268 seconds)
17:09:14 --- join: gianluca` (~user@188.29.165.117.threembb.co.uk) joined #osdev
17:09:20 <gamozo> I'm doing something slightly weird where I shutdown PXE and reinitialize it and when it comes back up it "doesn't work", I can see it's sending a packet out and getting one back but it just hangs
17:09:51 <gamozo> so it's able to transmit, and due to the transmit packet i assume it knows its address as it's using the right client IP and mac... but it must not have the filter set up on the RX side? idk
17:10:14 <gamozo> but more generically, I've seen PXE roms clobber segments (like hidden segment info, the PXE API is all real mode)
17:10:31 <gamozo> I've seen the APIs modify critical flags like the IF, where you call it with IF cleared and it returns with it set
17:10:48 <gamozo> and the PXE spec is so vague that there are multiple interpretations
17:10:53 --- quit: gianluca (Ping timeout: 260 seconds)
17:11:09 <gamozo> even for extremely basic use "download this damn file and put it in ram" there are many things that can go wrong firmware-to-firmware
17:11:39 <gamozo> there's also a bulk/atomic READ_FILE API that reads a while file (rather than issuing a read request for each packet)
17:11:47 <gamozo> this API just generally never works in practice
17:11:54 <doug16k> wow
17:11:55 <gamozo> I think only 1 or 2 firmwares I've ever seen it actually works
17:13:54 <gamozo> it also provides UDP and just generic packet read/write stuff, I've never used that so I can't speak to it
17:14:03 <gamozo> I think most people just use it to TFTP read a file for their stage 2
17:14:14 <doug16k> you'd think they could get TFTP to work. how could it be any simpler?
17:14:49 --- join: appa2 (~appa@d199-74-162-107.nap.wideopenwest.com) joined #osdev
17:15:24 <doug16k> I made a Qt PXE DHCP responder with integrated TFTP server a while back: https://github.com/doug65536/pxedhcp
17:15:25 <bslsk05> ​doug65536/pxedhcp - PXE DHCP responder with built-in TFTP server (3 forks/1 watchers)
17:15:50 <gamozo> I think the issue is the spec is too vague so implementations all conform to it but differently
17:16:09 <gamozo> further the spec is from 1999 and has never been reved...
17:16:22 <gamozo> even just to clarify things
17:16:40 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
17:17:06 <gamozo> and since they're ROMs you can't really debug them, so you blindly have to hope PCAPs + some logic can fix your issues
17:17:27 <gamozo> oh yeah, some firmwares negotiate incorrect packet sizes
17:17:56 <gamozo> "hey, I'd like to open a file for reading using 512 byte chunks (standard chunk size for PXE/TFTP)"
17:18:11 <gamozo> and then it proceeds to use >512 byte chunks
17:18:18 <gamozo> it's just all kinds of fucked
17:18:28 <doug16k> you can get seabios source and rebuild it to with debug message spam
17:18:47 <gamozo> the sisue is it's always portability
17:18:53 <gamozo> getting PXE to work on one ROM is ezpz
17:19:03 <gamozo> especially something like iPXE where you have full source
17:19:05 <doug16k> yeah won't solve bare hardware problems but could reveal a bug or two
17:19:39 --- quit: grange_c (Quit: Lost terminal)
17:20:31 <doug16k> with your experience with it, you could revise the spec with your empirical observations, like "IF must be set here" or "may return with messed up hidden segment descriptors loaded" etc
17:21:40 <gamozo> https://github.com/ipxe/ipxe/blob/827dd1bfee67daa683935ce65316f7e0f057fe1c/src/arch/x86/interface/pxe/pxe_preboot.c#L267
17:21:42 <bslsk05> ​github.com: ipxe/pxe_preboot.c at 827dd1bfee67daa683935ce65316f7e0f057fe1c · ipxe/ipxe · GitHub
17:21:43 <doug16k> I'm curious why you would call it with interrupts disabled
17:21:45 <gamozo> this comment is a good summary of the PXE spec
17:21:54 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
17:22:04 <gamozo> I mean, this is all done in real mode before anything is really set up
17:22:10 <gamozo> so generally i don't have interrupts enabled
17:22:14 <gamozo> i just want my stage 2
17:23:28 <doug16k> shouldn't 0xa0000 actually be 0x9fc00? https://github.com/ipxe/ipxe/blob/827dd1bfee67daa683935ce65316f7e0f057fe1c/src/arch/x86/interface/pxe/pxe_preboot.c#L271
17:23:30 <bslsk05> ​github.com: ipxe/pxe_preboot.c at 827dd1bfee67daa683935ce65316f7e0f057fe1c · ipxe/ipxe · GitHub
17:23:43 <doug16k> you're going to crap on the EBDA
17:24:11 <doug16k> or better, use the actual value from the BDA
17:24:43 <gamozo> yeah probably
17:25:15 --- quit: gianluca` (Remote host closed the connection)
17:25:15 <gamozo> that would be a fun test, PXE reset with a larger image
17:25:20 <gamozo> would probably break everything
17:25:26 <gamozo> welcome to PXE roms
17:25:45 <gamozo> spin the wheel, pick a random line, probably has a bug, breaks the spec, or is unimplemented
17:25:49 <geist> dude keep it real man
17:25:51 <doug16k> lol
17:25:55 <geist> dont need any protection
17:26:18 <gamozo> Did UEFI fix PXE? is there a new protocol that is better?
17:26:33 <heat> I don't think so
17:26:34 <gamozo> err actually can't UEFI just boot an arbitrary sized exe where you don't really need a bootloader anyways?
17:26:37 <geist> i think so. UEFI implementations can do PXE usually, though i think they then interpret the thing as PE
17:26:51 <gamozo> i only use PXE literally to load a >32KiB kernel, I already use a PE for my kernel
17:26:53 <heat> yeah but it's still PXE right?
17:26:54 <geist> dunno if that's part of the UEFI spec or if it' just an implementation
17:27:03 <gamozo> ah
17:27:05 <geist> well, i guess the 'load from some tftp server' part
17:27:17 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
17:27:18 <geist> i dunno about the rest of it, since i thought PXE had this whole real mode environment along with it
17:27:27 <gamozo> I would just have hoped we weren't still traversing to real mode every packet we send a receive
17:27:40 <geist> ah. no i guess it's PXE emulation then
17:28:01 <gamozo> PXE has a protected mode stack
17:28:03 <heat> UEFI does have a network stack so I guess you don't really have to use PXE
17:28:05 <gamozo> however by spec it implements nothing
17:28:07 <gamozo> wooooooo
17:28:18 <geist> sound like VBE or whatnot
17:28:27 <geist> good idea, no one cared, no one implemented
17:28:34 --- quit: rain1 (Quit: WeeChat 2.0.1)
17:28:38 <gamozo> there's a PXE_READ_FILE that lets you read to a 32-bit address with a 32-bit size, however it's limited to only <1MiB addresses in practice
17:28:39 <doug16k> gamozo, UEFI spec has "15.3 PXE Base Code Protocol" section
17:28:56 <geist> somewhere i actually have a NE2k card with some loader on a flash chip that slurps a binary from somewhere into memory and jumps into it
17:29:19 <gamozo> i just don't get why it's so freaking hard for bioses to initialize ram, and put an arbitrary sized thing (not fucking 512 bytes) from disk/network/etc into memory and jump to it
17:29:26 <geist> someone gave it to me, was nice to hack with
17:29:44 <geist> gamozo: who slow down slick. need a committee for that
17:29:55 <gamozo> liek when I did my RPI kernel, any size blob worked
17:30:01 <geist> next meeting at a shitty Ramada Inn off the turnpike in.... 2027
17:30:20 <gamozo> I abused it so much and just started including huge 10-100 MiB blobs in my .data section rather than implementing a network driver for the pi itself
17:30:29 <gamozo> heh
17:30:54 <gamozo> I hope to get rid of all legacy BIOS code soon, I think once I get a new box I'm gonna sell my AMD box that is BIOS only
17:30:55 <doug16k> gamozo, look for the string DhcpDiscover in whatever reference you use for UEFI, should take you roughly there
17:31:00 <gamozo> and at that point I'll only be UEFI
17:31:28 <geist> yeah the only bios only machines i still have in circulation are some older (2010 era) atoms and my firewall box
17:31:36 <gamozo> I've never used UEFI at all so I'm not too familiar with the spec format, but I'll give it a look
17:31:46 <geist> the atoms i mostly keep around because they suck and are a good test that your stuff is backwards compatible with shit
17:31:48 <gamozo> does UEFI typically work in emulators/hypervisors?
17:31:55 <gamozo> I do some testing in Hyper-V and bochs
17:32:01 <gamozo> IIRC bochs doesn't support it?
17:32:30 <geist> well, technically any older emulator probably could if you just port UEFI to it. qemu for example has a UEFI port for many architectures, including x86
17:32:30 <doug16k> gamozo, you might have to build a recent custom configured seabios. not sure it's there though
17:32:36 <doug16k> don't rely on the default bochs rom
17:32:58 <geist> virtualbox and hyperv and vmware esx at least i know to have UEFI implementations
17:33:00 <doug16k> it's very easy to build seabios
17:33:39 <gamozo> any other nice benefits to UEFI? Do I still use E820 and cross check against it?
17:33:41 <geist> doug16k: i thought seabios was a legacy BIOS implementation? usually you build tianocore or whatnot
17:33:48 <geist> gamozo: no. uefi has it's own equivalent
17:33:50 <gamozo> or have to heavily use ACPI to get processor info and memory routings?
17:33:58 <gamozo> is it better/worse/easier to access?
17:33:59 <geist> yes but that hasn't changed
17:34:09 <geist> ACPI is still a thing and you still need to deal with it, same in uefi
17:34:13 <doug16k> geist, recent seabios has nvme support. is that "legacy"
17:34:29 <geist> doug16k: sure but i mean its a bios implementation not a uefi implementation, right?
17:34:39 <doug16k> not sure. you may be totally right
17:35:09 <geist> it's definitely the defacto open source bios impl. the firewall box i was talking about has a seabios implementation
17:35:29 <heat> afaik seabios doesn't do UEFI at all, it's a pure x86 BIOS
17:35:47 <geist> it's a bit wonky because it's headless, etc. UEFI is better about that, since it's designed to be usable in a headless/serial only environment
17:35:58 <heat> if you want UEFI you'll build tianocore(?) for qemu or something
17:36:22 <geist> yah and there are prebuilts for it, you can pass a -rom switch to qemu to just tell it to use that instead of the default bios implementation it picks if you dont overload it
17:36:48 <geist> last i tried it was for some reason really slow on x86 qemu. took like 10 seconds to post or whatnot. dunno why
17:37:22 <heat> yeah it takes a bit to post, depends on the amount of memory
17:38:17 <heat> and some configurations are broken(q35 doesn't work, the vmware gpu also makes it hang)
17:39:02 <geist> i've used the arm one though, and that one seems alright. has less stuff to do
17:39:18 <geist> useful for booting an arm server kernel on a qemu machine
17:39:52 --- join: dbittman (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
17:44:22 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
17:51:58 --- quit: daniele_athome (Ping timeout: 240 seconds)
17:53:05 <gamozo> fuck this, ill rewrite my soft reboot stack to not use PXE on the second round
17:53:16 <gamozo> PXE will be used for boot but then if I soft reboot I'll have to use my networking stack
17:53:18 --- join: daniele_athome (~daniele_a@93.40.14.81) joined #osdev
17:53:29 <gamozo> just annoying cause I wanted to be able to completely trash my kernel and still be able to soft reboot
17:55:36 <ox6> is there a reset or anything in the api
17:56:00 <ox6> most fw roms I have used weren't meant to be re-entered after they had handed off
17:57:19 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
18:10:48 --- quit: Belxjander (Ping timeout: 276 seconds)
18:12:09 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
18:14:12 --- quit: gdh (Quit: Leaving)
18:22:17 <graphitemaster> haha christ https://lackingrhoticity.blogspot.ca/2018/01/observing-interrupts-from-userland-on-x86.html
18:22:19 <bslsk05> ​lackingrhoticity.blogspot.ca: Lacking Rhoticity: Observing interrupts from userland on x86
18:22:25 <graphitemaster> can we just admit we can't computer
18:23:23 <heat> ok i give up now
18:23:33 <graphitemaster> who needs timers at all
18:23:46 <graphitemaster> just play with the gs register and measure interrupt CYCLE ACCURATE
18:24:20 --- quit: Belxjander (Ping timeout: 240 seconds)
18:24:28 <Mutabah> wait, gs is clobbered? Oh, x86-64
18:29:45 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
18:31:45 --- quit: dude12312414 (Quit: Segmentation fault: 11)
18:34:36 --- join: Humble (~hchiramm@223.186.90.210) joined #osdev
18:34:59 --- join: renopt (~renopt@unaffiliated/renopt) joined #osdev
18:37:36 --- join: dude12312414 (None@gateway/shell/elitebnc/x-ahqhcppkaqjwrbcg) joined #osdev
18:41:58 --- quit: chaignc (Quit: No Ping reply in 180 seconds.)
18:42:35 --- join: sinetek_ (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
18:42:39 --- quit: hunterlabs (Ping timeout: 276 seconds)
18:43:11 --- quit: sinetek_ (Client Quit)
18:43:13 --- join: chaignc (~yes@2001:41d0:8:fbb::1) joined #osdev
18:45:07 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-vftamupvususzsnx) joined #osdev
18:45:10 --- join: sinetek_ (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
18:46:39 --- quit: heat (Remote host closed the connection)
18:50:27 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-mkouylzxrtqgnlyv) joined #osdev
18:52:30 --- quit: ohnx (Ping timeout: 255 seconds)
18:58:44 --- join: ohnx (~ohnx@unaffiliated/ohnx) joined #osdev
18:59:44 --- quit: tacco\unfoog ()
19:27:27 --- join: uvgroovy (~uvgroovy@c-65-96-163-219.hsd1.ma.comcast.net) joined #osdev
19:29:00 --- quit: uvgroovy (Client Quit)
19:29:17 --- join: uvgroovy (~uvgroovy@2601:184:4980:e75:6d8c:671b:a48a:2633) joined #osdev
19:35:12 --- quit: uvgroovy (Ping timeout: 265 seconds)
19:39:58 --- quit: SN4T14 (Ping timeout: 240 seconds)
19:40:58 --- quit: mlen (Ping timeout: 240 seconds)
19:41:11 --- join: SN4T14 (~SN4T14@2a00:d880:5:13e::579a) joined #osdev
19:41:32 --- quit: __pycache__ (Quit: bye-nyan!)
19:41:51 --- join: m712 (~annoying@unaffiliated/thefam) joined #osdev
19:42:27 --- quit: Belxjander (Ping timeout: 276 seconds)
19:43:09 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
19:45:58 --- quit: freakazoid0223_ (Ping timeout: 248 seconds)
19:47:56 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
19:48:34 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-wjhsignvfwsgogfa) joined #osdev
19:50:08 --- quit: JusticeEX (Ping timeout: 260 seconds)
19:55:59 <latentprion> Hey, I don't remember how nested IRQs work on x86-64
19:56:33 <latentprion> BAsically on IA-32, the CPU only used to push and pop SS:ESP if the interrupt triggered a privilege level change
19:56:44 <latentprion> And this allowed you to have nested IRQs very easily on IA-32
19:57:17 <latentprion> In long mode, the CPU always pushes SS:ESP, and it always loads ESP from the TSS/IST, so you can't easily have nested IRQs
19:57:27 <geist> what do you mean? why not?
19:57:45 <Mutabah> It only uses the TSS if a level change happens
19:57:57 <Mutabah> and afaik the IST is only used if you've specified to in the IDT
19:57:59 <geist> yah and it pushes ss:rsp because it automatically aligns the stack
19:58:12 <geist> but it pushes it at the instant it happened, so it nests just fine
19:58:32 <latentprion> But it says it pushes SS:ESP unconditionally, and unconditionally pops them too, even when there's no privilege change
19:58:46 <geist> yes, but that's fine. pushing/popping it is okay
19:58:53 <latentprion> Ah, ok I see, I was being dense
19:58:54 <geist> its loading it from TSS that it only does when doing a priviledge change
19:59:01 <latentprion> Right
19:59:43 <geist> the always push is IIRC entirely becuase of the auto-alignment thing it does
20:00:12 <latentprion> Right, makes sense thanks
20:10:14 --- join: mlen (~mlen@hawk.aquila.re) joined #osdev
20:14:44 <gamozo> man it's sometimes so relaxing to just step away from code :P
20:14:59 <gamozo> I'm trying to ramdisk boot windows, and it's just brainless trying stuff
20:15:05 <gamozo> but no stress
20:15:07 --- quit: mpascale00 (Quit: mechanist has disapparated...)
20:17:20 <geist> word to that
20:17:28 <gamozo> the PXE stuff had me fuming
20:17:58 <Kazinsal> PXE in a nutshell right there
20:18:14 <gamozo> how can you possibly screw up TFTP?
20:19:33 <gamozo> gamozoPXE v1.0: API functions, acquire_dhcp(), set_static_ip(), set_server_ip(), get_server_ip_from_dhcp(), download_image(const char *filename, void *dest)
20:19:36 <gamozo> DONE
20:22:42 <mischief> read the uefi specification for a good time
20:23:40 <gamozo> i might be a skeptic of that statement
20:25:29 --- part: darthdeus left #osdev
20:34:24 --- join: promach_ (~phung@155.69.206.255) joined #osdev
20:38:21 --- quit: navidr (Quit: Connection closed for inactivity)
20:47:20 --- quit: awang (Ping timeout: 240 seconds)
20:56:03 --- quit: hppavilion[1] (Ping timeout: 260 seconds)
20:56:54 --- quit: king_idiot (Ping timeout: 248 seconds)
20:58:37 --- join: wcstok (~Me@c-71-197-192-147.hsd1.wa.comcast.net) joined #osdev
21:01:38 --- quit: banisterfiend (Quit: Textual IRC Client: www.textualapp.com)
21:02:02 --- join: oaken-source (~oaken-sou@p3E9D2243.dip0.t-ipconnect.de) joined #osdev
21:02:50 --- quit: quc (Ping timeout: 246 seconds)
21:11:16 --- quit: ox6 (Remote host closed the connection)
21:11:38 --- join: ox6 (836bae30@gateway/web/cgi-irc/kiwiirc.com/ip.131.107.174.48) joined #osdev
21:11:53 --- part: pixelherodev left #osdev
21:13:15 --- join: pixelherodev (znc@irc.sircmpwn.com) joined #osdev
21:20:15 --- join: quc (~quc@host-89-230-168-134.dynamic.mm.pl) joined #osdev
21:22:26 --- quit: ox6 (Changing host)
21:22:26 --- join: ox6 (836bae30@unaffiliated/ox6) joined #osdev
21:22:26 --- quit: ox6 (Changing host)
21:22:26 --- join: ox6 (836bae30@gateway/web/cgi-irc/kiwiirc.com/ip.131.107.174.48) joined #osdev
21:29:10 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:29:53 --- quit: freakazoid0223 (Quit: On the other hand, you have different fingers.)
21:31:55 --- quit: appa2 (Ping timeout: 264 seconds)
21:36:35 --- quit: variable (Quit: /dev/null is full)
21:50:03 --- quit: quc (Remote host closed the connection)
21:50:16 --- join: quc (~quc@host-89-230-168-134.dynamic.mm.pl) joined #osdev
22:01:28 --- join: xenos1984 (~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120) joined #osdev
22:10:18 --- quit: dbittman (Ping timeout: 252 seconds)
22:17:07 --- quit: ohnx (Ping timeout: 265 seconds)
22:29:09 --- quit: sinetek_ (Quit: This computer has gone to sleep)
22:29:38 --- quit: pictron (Remote host closed the connection)
22:42:36 <doug16k> graphitemaster, that won't happen in my kernel, I save and restore all of the segments, and keep user mode data segments loaded at all times - they won't be RPL=0 ever, so they won't be subject to the nulling out behaviour
22:43:00 <doug16k> I skip loading them if they aren't changing though. reading a segment register is 1 cycle
22:44:03 <Mutabah> doug16k: From what I read of that article, the problem is that IRET will check if the selector is valid, and sets it to zero if it isn't
22:44:04 <doug16k> long mode CPL=0 doesn't care about the data segments, at all
22:44:22 <Mutabah> So user sets GS to 1, IRET sees that it's 1 and sets it to 0
22:44:28 <doug16k> ah I see
22:44:38 <doug16k> who cares if they detect an interrupt anyway?
22:44:52 <doug16k> useless side channel
22:46:07 <doug16k> you could terminate the process if they have a null segment. bye bye side channel
22:46:37 <doug16k> but then another process could detect that it exited. ok, terminate any process that waits for it to exit
22:46:44 <Mutabah> except that in x86-64, null gs is valid
22:47:21 <doug16k> on interrupt entry, terminate the process if their context has a null data segment, in any segment register
22:47:29 <geist> yah i don thtink there's a way to protect with that particular side channel
22:47:38 <geist> i thought about it a bit too, but it's basically present on all x86s
22:47:40 <doug16k> why not? they have no business touching them in 64 bit code
22:48:50 --- quit: Humble (Ping timeout: 256 seconds)
22:49:08 <doug16k> geist, terminating the process won't protect against it?
22:49:36 <geist> hmm?
22:49:48 <geist> i'm out of sync here with who is responding to what
22:50:05 <geist> my understanding of the segment register thing is if user space touches it then it gets whacked back to zero
22:50:13 <geist> could terminate i guess, but i'm not sure what that's protecting against
22:50:17 <doug16k> the "detect interrupt because IRET nulls out RPL=1 to RPL=3 and selector index=0
22:50:31 <geist> yeah but getting whacked detects it too,so i'm not sure what it helps you with
22:51:05 <doug16k> which goes back to, who cares if they detect interrupts
22:51:07 <geist> and you can probably detect an interrupt in a bazillionother ways
22:52:02 --- quit: srjek (Read error: Connection reset by peer)
22:54:59 <promach_> For https://paste.ubuntu.com/26358306/ , what does "mmc0: Card stuck in programming state! mmcblk0 mmc_blk_err_check" mean ?
22:55:00 <bslsk05> ​paste.ubuntu.com: Ubuntu Pastebin
22:55:32 <Mutabah> From the message, I'd assume it's a bad SD card that's not reporting that a write completed
22:55:36 <geist> yeah
22:55:39 <doug16k> promach_, I'd say the card is toast
22:55:43 <Kazinsal> Yeah, that's a bum card
22:55:59 <geist> reset everything and hope it doesn't happen again
22:56:08 <Kazinsal> RIP cheap SD card, you lasted all of ten minutes that boot
22:56:08 <geist> if it's a soldered down chip, then bummer
22:57:15 <promach_> doug16k: I had copied the img file to the SD card using dd
22:57:33 <promach_> and that SD card was working OK previously
22:57:50 <doug16k> everything worked okay before it failed
22:58:03 <Kazinsal> Block mighta gone and befuckered while you were writing it
22:58:06 <Kazinsal> How old's the card?
22:58:25 <Kazinsal> Have you ever actually filled the card up to be sure it's not a lower capacity knockoff
22:59:14 <promach_> not a lower capacity knockoff ????
22:59:38 <doug16k> lots of nasty manufacturers make the device lie about its size and mislabel it
22:59:40 <Kazinsal> Yeah, a bootleg card that's actually like, 512 megs flashed to say it's several gigs
22:59:52 <Kazinsal> Usually ghost runs from China
23:00:25 <promach_> that SD card is from Taiwan
23:00:37 <Kazinsal> Well, it *says* that
23:02:24 <doug16k> when you dd it, make sure you pass oflag=direct,sync
23:03:34 <doug16k> it's possible that it was buffered writing and you ripped it out while it was writing
23:04:13 <doug16k> those flags will make it wait until it is all written before showing the command prompt
23:04:26 --- join: alphawarr1or (uid243905@gateway/web/irccloud.com/x-sedkwncuxgriorqp) joined #osdev
23:05:08 <Mutabah> Probably also pass bs=1M or similar, to make dd write in large blocks
23:06:37 --- join: user10032 (~Thirteen@90.209.104.11) joined #osdev
23:06:48 <doug16k> yeah, the default output block size is 512. a large block size will be faster and probably reduce wear on the flash
23:13:31 --- quit: wcstok (Read error: Connection reset by peer)
23:14:15 --- join: ohnx (~ohnx@unaffiliated/ohnx) joined #osdev
23:16:26 --- join: retpolin_ (~clickjack@199.254.238.198) joined #osdev
23:17:50 --- quit: zwliew (Quit: Connection closed for inactivity)
23:17:54 --- quit: retpoline (Ping timeout: 240 seconds)
23:17:56 --- quit: Belxjander (Ping timeout: 268 seconds)
23:18:15 --- nick: retpolin_ -> retpoline
23:24:32 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:31:15 --- quit: sprocklem (Ping timeout: 276 seconds)
23:34:06 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-zbgznpdhcqcnmsri) joined #osdev
23:41:31 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
23:50:02 --- quit: quc (Remote host closed the connection)
23:50:18 --- join: quc (~quc@host-89-230-168-134.dynamic.mm.pl) joined #osdev
23:59:59 --- log: ended osdev/18.01.09