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=2

Tuesday, 2 January 2018

00:00:00 --- log: started osdev/18.01.02
00:00:02 <geist> even easier, just swap the cables
00:00:16 <Kazinsal> even even easier, hit delete while POSTing
00:00:17 <geist> come on get in there and get your hands dirty, do it for great justice
00:00:21 <heddwch> graphitemaster: That's kinda like jumper settings, except behaves like jumper settings
00:00:51 <heddwch> Set everything to CS, plug it in, don't care until it doesn't boot, then you know what disk number you installed on :p
00:01:13 <graphitemaster> I remember modding IDE cables back in the day to make them CS capable
00:01:13 <geist> windows/dos used to be a lot pickier about drive order
00:01:17 <bcos> If it's new enough to have SATA; buy a nice new SSD and boot from that :-)
00:01:21 <geist> but nowadays i think it's good enough to just deal
00:01:21 <graphitemaster> the 28th wire, just cut it out
00:01:43 <geist> i never really trusted CS select wires, always did it with the jumpers
00:01:59 <heddwch> graphitemaster: Yea, 80 terminal cables =/ Technically not necessary for CS, but try to convince a stupid Hitachi drive of anything other than its own opinion..
00:02:27 <graphitemaster> the high speed ones were harder, you had to deshield and solder to skip the slave part
00:02:29 <graphitemaster> painful
00:02:37 <heddwch> D: Never tried haha
00:02:54 --- quit: hunterlabs (Ping timeout: 252 seconds)
00:02:55 <heddwch> If it was >3.5GB, all it has to do is coexist with a CD-ROM :P
00:03:09 <geist> oh no! dont do that
00:03:12 <graphitemaster> this way http://www.unixwiz.net/images/ide-cable-select-hard.gif
00:03:15 <geist> cdroms slow down your HD bigtime
00:03:26 <heddwch> D: haha
00:03:42 <heddwch> Oh, yea
00:04:01 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-jhbxrznugfgbohyo) joined #osdev
00:04:06 <graphitemaster> the 80 cables (ultra DMA?) were CS compatible iirc
00:04:08 <graphitemaster> out of box
00:04:09 <heddwch> but I'm a 486 on a single user workload :p No CD activity, and if there is, I'm trying to play warcraft anyway
00:04:10 <geist> if you could you always wanted to put the cdrom on its own cable, since it could hold the bus while it was transferring
00:04:25 <heddwch> Oh, it's on its own cable out of my control.
00:04:31 <geist> but then having two hds on the same cable vs a cdrom on a second one was a tossup
00:04:41 <heddwch> Board only has ATA, SB16 has another ATA channel that only supports ATAPI
00:05:15 <graphitemaster> you know what I did to all my old IDE cables. I pulled each strand of wire off individually from it, but kept them sheilded, they make for nice pieces of wire in electrical projects, some I kept together for ribbon like connections to PCBs, really nice wire
00:05:37 <geist> yeah 40 pin ribbon cables are a nice way to bridge two boards together
00:06:07 <heddwch> Volume in drive C is MS-DOS_6
00:06:07 <heddwch> Directory of C:\
00:06:08 <geist> the pinout is a standard plug pitch, easy to get
00:06:19 <graphitemaster> I wonder if I could get that in a roll
00:06:30 <heddwch> Volume in drive C is MS-DOS_6
00:06:30 <heddwch> Directory of C:\
00:06:34 <graphitemaster> so I don't have to cut the ends off and so I can get larger lengths
00:06:35 <heddwch> gr, sorry
00:06:37 <geist> heddwch: please to be not beating us over the head with the YOURE USING A 486 thing
00:06:38 <heddwch> Volume in drive C is MS-DOS_6
00:06:38 <heddwch> Directory of C:\
00:06:41 <heddwch> fuck
00:06:47 <heddwch> geist: Fair, sorry
00:07:08 <geist> i bought a 386 off ebay the other day. was stymied with a dead CMOS battery though
00:07:17 <Kazinsal> hokey religions and ancient microcomputers are no match for a good Power Mac at your side
00:07:23 <geist> i'll get that fixed once i get a decent enough soldering iron to desolder the DS1287 CMOS chip
00:07:27 <heddwch> That really wasn't intentional, just you try to get used to ^ins and shift-ins instead of ^C/^V lol
00:07:38 <geist> ah yeah
00:07:39 <graphitemaster> CMOS battery isn't removable?
00:08:08 <geist> nope. not a DS1287. it's basically a bigass square chip, which turns out to actually be a CMOS chip with a battery and oscillator molded into the package
00:08:14 --- join: bm371613 (~bartek@2a02:a317:603f:9800:391:ed9f:1c09:1285) joined #osdev
00:08:21 <geist> only way to remove it is to Dremel out the battery and/or desolder it and replace
00:08:22 <graphitemaster> I guess that FCC regulation came later eh, when they required all batteries be removable in electronic devices
00:08:41 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
00:08:42 <heddwch> geist~2: fuck, yea, mine's the same. If I don't wait more than a week, the CMOS survives but I set the RTC every boot. no biggie, but yea, the other systems are mostly dead is why I went to the 486. It was a cute fun, project, yea, but now it's the system that still works -_- I'd rather not.
00:08:49 <graphitemaster> which is interesting because cellphone batteries are no longer removable so that must be violating that FCC regulation
00:09:03 <graphitemaster> Or maybe they classify it as "removable if you take it apart"
00:09:09 <geist> trouble is for whatever reason this 386 forgets its brains even if you warm reboot it
00:09:14 <geist> it insta-forgets anyuthing you set
00:09:29 <geist> http://www.mcamafia.de/mcapage0/dsrework.htm
00:09:29 <bslsk05> ​www.mcamafia.de: Reworking the DS1287 / DS1387 RTC chip
00:09:36 <heddwch> ah fuck, they always do unless you constantly feed them 4.2+ volts lol
00:09:49 <heddwch> If you need, I've got a link for 3x AA holders on eBay :p
00:10:11 <geist> yeah, trouble is you really need to remove the chip to do any real work on it, it's near a bunch of other crap so i can't even come in from the side
00:10:20 <heddwch> yea -_-
00:10:22 --- quit: vdamewood (Remote host closed the connection)
00:10:24 <graphitemaster> haha, they put a fucking battery in the clock chip
00:10:25 <graphitemaster> wtf
00:10:32 <geist> but then removing an old dip chip like that is much easier from the top, where you can use a rework gun to heat up all the pins at once
00:10:39 <graphitemaster> how times have changed
00:10:42 <heddwch> Nothing's to spec, but usually just feeding >4 to the funky 4-pin header however it wants it magically works.
00:10:46 --- quit: hunterlabs (Ping timeout: 250 seconds)
00:10:50 <geist> but since it covers the pins from above you only can come at it from below
00:11:04 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
00:11:06 <geist> but my solder foo is not good enough to remove a DIP from below without a specialized solder tip
00:11:08 <heddwch> geist: That's what she said, and she was wrong.
00:11:15 <heddwch> ~1*
00:11:17 <geist> and/or a solder iron that gets hotter than mine apparently does
00:11:46 <heddwch> fuck it, 0~1 are good messages for that too
00:11:55 <geist> my old sparcstations have the same problem, they've all forgotten their brains
00:12:07 <geist> but they usually deal with it once you power it up once and never cold boot
00:12:09 <heddwch> hehe
00:12:15 <heddwch> geist: Ever played with old world PPC and older macs?
00:12:26 <geist> negative
00:12:29 --- quit: raphaelsc (Remote host closed the connection)
00:12:33 <heddwch> Congratulation
00:12:34 <heddwch> s
00:12:41 <heddwch> because they really forget their shit -_-
00:12:50 <geist> actually that's not true, the G4 cube i have has some sort of brain-forgetting problem last i played with it
00:13:00 <graphitemaster> clang in web (compiled to webassembly/js) compiling C++ into WebAssembly all from Javascript then running it in your browser: https://tbfleming.github.io/cib/
00:13:01 <bslsk05> ​tbfleming.github.io: Clang In Browser
00:13:07 <geist> it wouldn't post, until you find some little microcontroller reset button hidden deep inside, then it boots exactly once
00:13:20 <geist> though that's a new world ppc
00:13:37 <Kazinsal> I need to pick up an old 68030 Mac
00:13:40 <heddwch> yay booting five times holding the right option-command-o-f until it gives a prompt if you're on a lucky machine video instead of serial controller, then just, you know, enter the fucking bootloader loader again in forth with no line editor.
00:14:11 <heddwch> tbf, that's way better than unpredictable BIOS, but yea, still hurts.
00:14:17 <geist> i haven't fired up my G5 powermac in years, but i have a little G4 mac mini somewhere, last i tried it ran fine
00:14:53 <geist> Kazinsal: yeah i get nostalgic about 68ks sometimes. i was thinking it'd be fun to build a board around an 020, which i think are super easy to find
00:15:13 <geist> dunno why, i never owned one. but you can get nostalgic about stuff you never had the first time
00:15:32 <heddwch> 68k macs were gorgeous pieces of engineering
00:15:32 <heddwch> and fucking awful to run anything but macos on
00:15:33 <heddwch> so probably perfect OS dev boxes.
00:15:36 <graphitemaster> geist, oh man, remember revision (the demoscene group)?
00:15:41 <heddwch> Oh yea, I know
00:15:42 <geist> i do not
00:15:43 <doug16k> I bought a book about 68030 motherboard design many years ago, I loved it. insanely technical
00:15:55 <Kazinsal> My first actual useful computer was a Macintosh Performa 580CD
00:16:05 --- join: nzoueidi (~nzoueidi@ubuntu/member/na3il) joined #osdev
00:16:16 <heddwch> I spent ~$200 piecing together a Mac IIci with way too much RAM and one of two external CD drives to run A/UX 3.0.5
00:16:19 <graphitemaster> geist, well, they're taking demoscene to the webbrowser, they did their first web demo http://arkt.is/no-invitation/
00:16:21 <Kazinsal> Basically an LC575 with an IDE hard drive instead of a SCSI drive meant to be sold in big box stores like Sears
00:16:27 <heddwch> They were fucking right there, too. Very good OS>
00:16:29 <graphitemaster> geist, and the demoscene is blowing up over it :P
00:17:36 <geist> Second Reality or GTFO
00:17:36 <graphitemaster> and also ... it's a revision 2018 ad, for demosceners
00:18:18 <heddwch> Kazinsal: hehe My first >8-bit was a 386/8MB running Win95 because I was dumb. First 'serious' was a 486DX33/12MB w/WfWG3.11
00:18:25 <bslsk05> ​arkt.is: No Invitation
00:18:25 <geist> https://www.youtube.com/watch?v=rFv7mHTf0nA man i remember losing my shit over that on my old 386
00:18:26 <bslsk05> ​'Second Reality by Future Crew (PC Demo)' by docannotable (00:16:30)
00:18:28 <geist> actually ran pretty good
00:18:45 <graphitemaster> second reality is amazing
00:19:26 <heddwch> That 386 w/OSR2 on a 250MB hard disk was amazing. Had the whole Tenchi Muyou theme for a login song, and an MP3 player that worked :p
00:19:29 <graphitemaster> geist, 8088 mph is better tho :P
00:19:35 <geist> oh hell yeah
00:19:42 <Kazinsal> 8088 MPH is a masterpiece
00:19:56 <heddwch> But yea, wasn't wise. 3.1 was more suitable for the next two iterations
00:20:59 <heddwch> DO LIKE THE IRONY
00:21:10 <graphitemaster> the live audience reaction to it at revision 2015 was awesome
00:21:13 <meowrobot> <geist> nope. not a DS1287. it's basically a bigass square chip, which turns out to actually be a CMOS chip with a battery and oscillator molded into the package <- what even
00:21:15 <graphitemaster> https://www.youtube.com/watch?v=gdb3AQ14iVc
00:21:16 <bslsk05> ​'8088 MPH Revision 2015 Live Audience Reaction' by Jim Leonard (00:08:56)
00:21:23 <meowrobot> i had no idea there were people who thought that was actually a good idea
00:21:29 <geist> meowrobot: yeah no kidding
00:22:00 --- join: promach__ (~phung@155.69.206.60) joined #osdev
00:22:08 <doug16k> geist, yeah, on a PIII 350MHz, you can see the sword completely come out of the clip plane on the clipped plane texture mapping demo. normally that part doesn't finish because the cpu is too slow :)
00:22:19 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-mjtmrzeyzrzkcqug) joined #osdev
00:22:25 <geist> but it's all good. the 386 machine i bought off ebay was the exact model i had as a kid,m and it's one of those things where the machine itself is really a card on some sort of ISA backplane
00:22:25 <heddwch> Bunch of variously modern computers that can't run a fucking terminal half decently, and the 486 is what I'm using because it always boots, always plays games, and always can restart within 5m :p
00:22:52 <geist> so it's essentially a full length card with 386 + memory + video (tseng labs 4000 SVGA i think)
00:22:57 <geist> so everything is very tight
00:23:10 <heddwch> ^ best terminal, w/DAs
00:23:12 <heddwch> ..
00:23:16 <heddwch> too many mac articles
00:23:19 <heddwch> s/DA/TSR/
00:23:30 <geist> heddwch: did you see that i got one of the altair 8800 clones. it's lovely
00:23:36 <heddwch> :D
00:23:51 <geist> it's a clone, of course, but the guy that made it clearly loves these things
00:24:00 <geist> it's a perfect external replica
00:24:13 <doug16k> what's that, an 8080?
00:24:19 <geist> yeah, 2Mhz 8080
00:24:33 <geist> thjough the altair ended up spawning the S-100 bus, which is basically the 8080s bus
00:24:36 --- quit: dbittman (Ping timeout: 276 seconds)
00:24:44 <geist> and then a bunch of other machines came along and used the same bus, even with different architectures
00:24:47 <heddwch> geist: I'm thinking RPi-ish whatever EvB w/TCP->TLS or serial->TCP/TLS is the right approach... Doesn't even count as cheating, because you would've used a similarish (probably MIPS) to get to your shell account in 1996 anyway
00:25:25 --- quit: Arcaelyx (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:25:28 --- quit: promach_ (Ping timeout: 272 seconds)
00:25:44 <heddwch> =w current time 8332
00:25:46 <heddwch> =w current time 83322
00:25:47 <geist> yeah been meaning to look into SLIP or something. curious what that looks like
00:25:48 <heddwch> ...
00:25:50 <heddwch> =w current time 83332
00:25:57 <heddwch> =wa current time 8333
00:25:59 <Kazinsal> most of basilisk's functions don't run here
00:26:00 <heddwch> =wa current time 83332
00:26:01 <geist> i suspect it's just IP packets with some sort of HDLC framing
00:26:04 <Kazinsal> because people kept spamming them
00:26:06 --- quit: KidBeta (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
00:26:06 <heddwch> ....
00:26:09 <heddwch> yea, no idea why
00:26:16 <heddwch> So sorry about that >
00:26:20 <heddwch> _>
00:26:37 <geist> also i played Rust some yesterady. nothing beats running around naked holding a rock beating on things
00:26:48 <heddwch> haha
00:26:48 <geist> and then getting ganked by some other naked dude with a rock
00:26:58 <geist> life simulation, right there
00:27:05 <doug16k> geist, I prevented G bit in all but PT pages, and it doesn't fault. I guess I'll have to give up on having recursive mapping having global bit for now
00:27:27 <geist> doug16k: hmm, so maybe the AMD manual is not exactly correct there and it's MBZ as well
00:27:43 <doug16k> I'm still completely convinced that it's KVM's fault
00:27:50 <doug16k> I could put it back and try bare hardware to be sure
00:27:51 * geist nods
00:34:04 --- quit: doug16k (Remote host closed the connection)
00:37:32 --- join: doug16k (~dougx@174-138-193-47.cpe.distributel.net) joined #osdev
00:40:57 --- quit: doug16k (Remote host closed the connection)
00:43:26 --- join: doug16k (~dougx@174-138-193-47.cpe.distributel.net) joined #osdev
00:43:48 <doug16k> geist, confirmed. works fine on bare hardware ryzen with those G bits set
00:44:27 --- quit: pictron (Remote host closed the connection)
00:44:32 <doug16k> that MBZ in PML4e is zero
00:44:37 --- quit: doug16k (Remote host closed the connection)
00:44:49 <geist> so here's my theory: rep outs forces some software in some layer to manually parse the page tables
00:45:02 <geist> and that code interprets the IGN of the G bit differently
00:45:05 --- join: doug16k (~dougx@174-138-193-47.cpe.distributel.net) joined #osdev
00:45:07 --- quit: Belxjander (Ping timeout: 264 seconds)
00:45:35 <geist> oh you dropped off
00:45:58 <doug16k> yeah. once in a while skype crashes my desktop right after boot
00:46:43 <doug16k> did I miss your response?
00:46:59 <geist> 00:44 < geist> so here's my theory: rep outs forces some software in some layer to manually parse the page
00:47:02 <geist> tables
00:47:04 <geist> 00:44 < geist> and that code interprets the IGN of the G bit differently
00:47:12 <doug16k> I agree 100%
00:47:51 <geist> actually raises some questions about the order of operations there
00:48:20 --- quit: garit (Ping timeout: 240 seconds)
00:48:24 <geist> if one cpu is off in KVM and another one has switched to software interpreting of page tables (assuming thats whats going on there) seems there are some interesting IPI races ad whatnot
00:48:57 <geist> if the other thread unmaps somethhing simultaneously seems the software page table code would need to be very very careful to access thigns in precisely the same way a real cpu would
00:49:22 <doug16k> yeah I was going to ask about that. right now, my mmap/munmap stress test spams IPIs _hard_. It pegs every core with tlb shootdown broadcasts
00:49:33 <doug16k> in munmap
00:49:58 --- quit: jack_rabbit (Ping timeout: 248 seconds)
00:50:03 <geist> i guess the IPIs dont really matter to the software page table walker, because its acting as if it has a 0 entry TLB
00:50:16 <geist> except it needs to access the page tables in a fairly careful way
00:50:16 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:50:24 <geist> ie, read each level precisely once, etc
00:51:00 <doug16k> yeah
00:51:27 <doug16k> but it's bad for performance to IPI _every_ munmap immediately right?
00:51:41 <doug16k> I was thinking I should be coalescing them - and keeping the physical pages allocated until every cpu completes the shootdown
00:51:52 <geist> generally yes, but then you should only have to IPI on cpus where it's mapped
00:52:11 <geist> and yes for operations like unmapping large runs of pages you should probably wait until the end
00:52:27 <doug16k> ya I do it at the end
00:52:38 <geist> but you have to be very careful when unmapping inner page tables
00:52:47 <geist> there's actually a subtle bug i'm working on with zircon on arm for that
00:53:05 <doug16k> bare hardware is mmap 64KB is 720 cycles. kvm is 900 cycles
00:53:07 <geist> unmapping a large run of pages you can generally delay until the end *except* for when you unmap inner page tables as a result. you need to flush that
00:53:33 <doug16k> I don't free page tables yet
00:53:35 <geist> mapping usually doesn't involve any TLB flushes, so that's usually just the speed of the software
00:53:54 <doug16k> ya sorry, random off topic comment :D
00:54:07 <doug16k> interesting that it is significantly quicker
00:54:55 <geist> note that the whole TLB flush IPI you should avoid like the plague so a) delay if you can and b) only IPI to cpus you need to and c) avoid manipulating kernel space as much as you can because it defeats (b)
00:55:25 <doug16k> I must IPI all cpus for kernel mapping changes right?
00:55:28 <geist> also note that TLB IPIs is an x86 artifact. most other architectures are smarter about it and dont require IPIs
00:55:51 <geist> you need to IPI for changes for all places where an address space is mapped. since kernel is usually mapped on all processors...
00:56:02 --- join: jack_rabbit (~jack_rabb@174.34.177.131) joined #osdev
00:56:11 <doug16k> yeah, obviously right? :)
00:56:46 <geist> this is one of the reasons i dont like the whole recursive page table thing, it ends up causing some sort of TLB flush noise that you have to deal with on SMP machines and whatnot
00:57:09 <geist> it's a cute trick that falls apart once the system gets complex enough
00:57:17 <geist> and thus why most real systems dont use it
00:57:21 <doug16k> how do I pick and choose which cpus to IPI though? isn't there a race?
00:57:28 <doug16k> I mean for user space mapping
00:57:49 <geist> we just keep some sort of bitmap of which cpus the address space is mapped on right now
00:58:01 <geist> and then a lock to switch to it, so it can't race
00:58:39 <geist> if that, might just be an atmic, but if you err on one iside of it i think it works out
01:00:18 <bcos> Often for kernel there's a larger "can't read/write this data while something else is modifying" problem that needs locks, and you can fold invalidation into that (e.g. using an "if my version != data structure's version ( invalidate stuff that was added to the list)" added as part of acquiring the lock) so kernel doesn't need IPIs for itself
01:01:23 --- quit: jack_rabbit (Ping timeout: 260 seconds)
01:01:44 <doug16k> I do have a versioning system for the page tables already, but nothing per-process, yet
01:02:17 <doug16k> I call it the "mmu_seq" named after TCP sequence number
01:03:00 <doug16k> when I change the kernel mappings I increment it. each cpu keeps track of the last sequence number it saw
01:03:52 * geist sleeps
01:04:17 <doug16k> so for example, on #PF I check the cpu's mmu_seq against the global mmu_seq, and if they differ, it is probably a lazy tlb fault
01:05:25 <doug16k> but only if it was a fault that shouldn't have occurred, after checking PTE
01:05:56 <doug16k> to try to handle a race where there is a PF but the IPI didn't get here yet
01:06:03 <doug16k> tlb shootdown ipi
01:07:14 <doug16k> kind of bad though. that line will ping pong around if I map often
01:07:44 <doug16k> solution is don't map often :)
01:11:18 --- quit: daniele_athome (Ping timeout: 248 seconds)
01:11:51 --- join: jack_rabbit (~jack_rabb@209.58.129.98) joined #osdev
01:12:38 --- join: daniele_athome (~daniele_a@93.40.14.81) joined #osdev
01:13:19 --- join: garit (~garit@94.197.121.212.threembb.co.uk) joined #osdev
01:13:19 --- quit: garit (Changing host)
01:13:19 --- join: garit (~garit@unaffiliated/garit) joined #osdev
01:13:25 <doug16k> bcos, yeah I think I follow. I was thinking of eliminating the tlb shootdown by queueing up physical memory deallocations until every cpu has done a timer tick. once the xadd returns cpus-1 then it frees the physical pages in that batch and frees the queue entry
01:13:55 <doug16k> ...to keep the physical pages alive until I am sure no TLBs still point to them
01:14:54 <doug16k> so with 8 cpus, the first 7 cpus just increment the "seen" count, and the 8th will free the pages and deallocate the queue entry
01:15:29 --- join: metaglog (~unkn@unaffiliated/metaglog) joined #osdev
01:19:16 <bcos> For an example; if kernel has a linked list of "foo" data structures and a spinlock to protect the list; then you could add a "current version" and maybe up to 32 virtual addresses that might need to be invalidated; and when acquiring the lock you'd do "updates = current_version - my_old_version; if(updates > 32) { flush all TLBs } else { for(entry = 0 to updates) { invalidate(slot[entry]); }
01:20:38 <bcos> ^ that's wrong (would want a circular buffer), but...
01:20:50 --- quit: osa1 (Remote host closed the connection)
01:21:06 --- quit: hmmmm (Remote host closed the connection)
01:21:11 <doug16k> so it will precisely invalidate certain pages, and if too many it says screw it and flushes whole tlb?
01:21:46 <doug16k> sounds reasonable
01:22:53 <doug16k> would have to incorporate some way of ensuring that all of the cpus visit that and only the last (cpu) visitor removes the queue entry
01:23:42 <doug16k> slot[entry] could contain the pid, I could ignore the ones for other pids. perhaps use pid -1 to mean kernel space which can't be ignored
01:24:11 <doug16k> other = other than the one running on that cpu now
01:24:36 --- quit: CheckDavid (Quit: Connection closed for inactivity)
01:27:32 <doug16k> and "removes the queue entry" would mean incrementing the queue head
01:33:21 --- quit: meowrobot (Quit: let us connect our intestines and mutually digest)
01:33:56 --- join: Asu (~sdelang@AMarseille-658-1-33-219.w86-219.abo.wanadoo.fr) joined #osdev
01:34:13 <bcos> There are a few problems with this though - you need to store "old version" for each thing somewhere (e.g. in a per-CPU area); and if you have a global kernel heap (with all kinds of data mixed with each other in a glorious tangled mess) then it becomes too hard (and you should probably forget about performance anyway) ;-)
01:35:03 --- join: meowrobot (~katgirl@pool-96-236-155-90.pitbpa.fios.verizon.net) joined #osdev
01:38:31 --- quit: Belxjander (Ping timeout: 264 seconds)
01:39:51 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:42:14 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
01:49:40 --- join: m_t (~m_t@93.218.45.133) joined #osdev
01:52:52 --- quit: Belxjander (Ping timeout: 272 seconds)
01:53:21 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:54:43 --- quit: jack_rabbit (Ping timeout: 264 seconds)
01:55:42 <garit> Ray tracing task for a scene with a million tiny mirrors and multiple reflections, which way of simulation is faster, ray as line(no need for steps, but have to check against every mirror in a scene) or ray as moving point(needs many steps, but allows localized interactions only)?
02:06:48 --- quit: Belxjander (Ping timeout: 248 seconds)
02:07:00 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
02:07:46 --- quit: dengke (Ping timeout: 252 seconds)
02:08:13 --- join: dengke (~dengke@106.120.101.38) joined #osdev
02:09:23 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
02:17:37 <doug16k> garit, I'd say as line. intersecting a ray with a polygon is a fairly cheap operation
02:18:37 <garit> thanks, i guess i have to find a good polygon vs line intersection algorithm then, if you think it exist
02:18:47 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
02:18:53 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
02:19:04 --- quit: eremitah (Ping timeout: 248 seconds)
02:19:23 <doug16k> when you say "a million" to you mean it literally?
02:19:45 <garit> Yes
02:20:18 <garit> all disconnected, small (round/square) chip of mirror
02:21:28 <doug16k> you would do both approaches. a bounding volume hierarchy and within each subspace, check against all mirrors in that subspace
02:21:43 --- join: eremitah (~int@unaffiliated/eremitah) joined #osdev
02:23:16 <doug16k> with some sort of batching system, where you have a bunch of rays that you do at once, and you find out which subspace they go to. they may go straight through to the following subspace or reflect off a mirror and get queued to enter a different subspace
02:23:41 <garit> ahh, so a ray first is checked in which volumes it is present and then analyzed there? So like a ball on a large scale and as a ray within that volume in details
02:23:54 <doug16k> something like that, yeah
02:30:57 <lava> geist: do you have a link to the fuchsia thing?
02:32:07 --- join: osa1 (~omer@213.14.66.114) joined #osdev
02:32:07 --- quit: osa1 (Changing host)
02:32:07 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
02:33:09 --- quit: doug16k (Remote host closed the connection)
02:34:45 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:34:56 --- join: doug16k (~dougx@174-138-193-47.cpe.distributel.net) joined #osdev
02:40:56 --- quit: AndrewBC (Ping timeout: 248 seconds)
02:41:12 <Levex> lava: #fuchsia may be of help
02:50:31 --- quit: Belxjander (Ping timeout: 264 seconds)
02:50:53 <bcos> garit: You can post-process space so that everything you'd see in a mirror (when looked at from a certain angle) is shifted behind the mirror. Then (assuming "perfect mirrors") you can delete the mirrors
02:51:49 <bcos> D'oh
02:51:56 <garit> bcos: but how would i know which mirrors reflect in which mirrors? And they are all very small, so that could create a lot of new objects
02:51:57 * bcos means "pre-process" there..
02:52:45 <garit> If i do know order of reflecrion and it angles(to solve this pre processing) its the same as solving the ray tracing itself
02:52:57 <garit> Reflection*
02:53:39 <bcos> It's "per mirror" rather than "per ray".
02:56:02 <garit> Does this take more time than a frame of ray tracing? (i need just 1 frame per position of mirrors, then all mirrors change their position a bit randomly)
02:56:18 --- quit: floatleft (Ping timeout: 260 seconds)
02:56:32 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
02:58:02 <bcos> Depends on resolution - if you're only casting 4 rays then..
02:58:45 <garit> Million rays, million mirrors
02:59:20 <bcos> Ok, in that case it's probably be equally bad either way
03:00:59 <garit> Yeah, i though so too. If you have any ideas what else can be done to simplify the task, share it =)
03:01:45 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-pfyucovewoigcund) joined #osdev
03:02:12 <bcos> Apart from mirrors, what else is there?
03:03:28 <bcos> ("calloc()" can be used to render an image with millions of mirrors; if all the background is black.. ;-)
03:04:13 --- join: Zerith (~Zerith@unaffiliated/zerith) joined #osdev
03:04:18 <garit> Source (non-zero sized tube in a center), and screen (a sphere distance x from a center)
03:04:35 <garit> and nothing else
03:05:15 <Zerith> Hey, can the BIOS intercept MMIO accesses somehow?
03:07:25 <bcos> garit: If the back side of a mirror is also a mirror and all of the sky is the same and all of the floor is the same; as soon as a ray hits a certain hieght you can forget about mirrors and just use sky/floor colour
03:08:50 <bcos> Zerith: Not easily (without extra hardware). There's no easy way for SMM code to figure out which physical address was used to trigger SMM
03:09:08 <garit> bcos: yes, there is only 2 colors - source shines light or no light at all
03:09:45 <garit> And intensity as if how many rays of source hits the screen in a particular place
03:09:59 <Zerith> bcos: is SMM code triggered as a result of an MMIO access?
03:10:05 --- quit: quc (Remote host closed the connection)
03:10:19 --- join: quc (~quc@87.116.237.223) joined #osdev
03:12:18 <bcos> Zerith: SMM code is triggered whenever hardware triggers it. The problem is that the SMM code has to figure out how to responds
03:13:23 <Zerith> mhm. I understand. cool
03:14:10 --- quit: Belxjander (Ping timeout: 268 seconds)
03:15:32 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
03:15:59 <Zerith> bcos: I'm dealing with a device that allows MMIO access for 2 separate devices - one is the host CPU and the other is a privileged device. It can somehow enforce permission checks on those write and I'm not sure how
03:18:43 --- quit: Barrett (Read error: Connection reset by peer)
03:18:53 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
03:26:01 --- join: alphawarr1or (uid243905@gateway/web/irccloud.com/x-pzixcuqkbdeluscw) joined #osdev
03:38:05 <bcos> Zerith: Maybe IOMMU?
03:44:42 --- join: fujisan (uid4207@gateway/web/irccloud.com/x-tlzwljlrfcjyeemf) joined #osdev
03:47:06 <Zerith> bcos: mhm that's interesting, what I see is that I have one big consecutive range of addresses, part of them I can read fine from the host, the others just read as zeroes. meanwhile from the privileged device, I can read the whole range and get the data. actually IOMMU might make sense, since these permissions seem to differ on 4096-byte ranges
03:48:12 <Zerith> Is there any way the device itself could know which device [cpu or priv.] accessed it?
03:48:28 <Zerith> maybe a separate interrupt for the cpu and the priv. device
03:48:54 <Zerith> they might not both be on the same address bus, so that could also be it
03:50:05 --- quit: quc (Remote host closed the connection)
03:50:16 --- join: quc (~quc@87.116.237.223) joined #osdev
03:51:54 <bcos> Zerith: If you send a "read request" to a device, everything between the device and you has to know where the "read reply"
03:52:09 <bcos> *where to send the "read reply"
03:52:39 <bcos> For old PCI it was simple (a tree where all replies go back towards CPU)
03:52:56 <bcos> ..but there was some extensions to make it possible for devices to talk directly to devices
03:53:21 * bcos never really looked into how those extensions worked
03:55:00 <bcos> Hrm
03:55:52 <bcos> Zerith: If you can get hold of "PCI express base specification" there's a description of "virtual channel mechanism" within the Transaction Layer section
03:56:30 --- quit: hunterlabs (Ping timeout: 276 seconds)
03:57:00 <Brnocrist> https://lkml.org/lkml/2017/12/27/2
03:57:00 <bslsk05> ​lkml.org: LKML: Tom Lendacky: [PATCH] x86/cpu, x86/pti: Do not enable PTI on AMD processors
03:57:03 <Brnocrist> oh, intel..
03:57:48 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-ieghfsvrhymimwse) joined #osdev
03:58:27 <Zerith> bcos: thanks, I'll look into that
03:58:51 --- join: inode (~inode@unaffiliated/inode) joined #osdev
03:59:11 --- join: floatleft (~floatleft@2.55.182.31) joined #osdev
03:59:50 --- nick: m712 -> __pycache__
04:02:19 --- quit: hunterlabs (Ping timeout: 255 seconds)
04:03:10 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-eklactkywnlibwec) joined #osdev
04:03:49 --- quit: floatleft (Ping timeout: 252 seconds)
04:04:17 <bcos> Brnocrist: "Security by obscurity" (kernel address space randomisation) that failed, and then needs a work-around (PTI) with a ~33% performance impact.
04:04:31 <Levex> 33%?
04:05:20 <Zerith> bcos: I'm pretty sure the device can differentiate between the cpu and the priv. device (Some values it won't let me put in some registers from the cpu).. can this make sense ?
04:06:07 --- join: m3nt4L (~asvos@2a02:587:a019:8300:3285:a9ff:fe8f:665d) joined #osdev
04:06:57 --- join: vmlinuz (~vmlinuz@2804:431:f725:afb6:a336:402:4cb3:b1cf) joined #osdev
04:06:58 --- quit: vmlinuz (Changing host)
04:06:58 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
04:08:02 <bcos> Zerith: Anything can make sense if you don't provide any useful details.. ;-)
04:08:31 <bcos> Levex: Estimates vary, but most sources seem to be saying "30% to 40% slower syscalls"
04:08:44 <Levex> Wow, last time I heard it was 5%
04:09:06 <bcos> "30% to 40% slower syscalls" might be the same as "5% slower processes"
04:09:17 <bcos> ^ depends how many syscalls a process does
04:09:25 <Levex> oh that makes sense
04:11:19 <bcos> What makes sense is making sure user-space can't do anything if it knows special kernel addresses (and ripping out the ASLR and PTI nonsense)
04:11:21 <bcos> l-)
04:11:53 <Levex> I agree, that would be the ideal solution
04:12:59 --- join: MarcinWieczorek (~MarcinWie@89-77-70-23.dynamic.chello.pl) joined #osdev
04:15:06 <bcos> Levex: Ironically; it makes the ideal of microkernels a lot more interesting.. ;-)
04:15:14 <bcos> *the idea of..
04:15:26 <Levex> Exokernels to the rescue! :-)
04:15:53 <bcos> ..I mean, if you're going to change TLBs on every privilege level switch why dick around? :-)
04:16:16 <Brnocrist> AMD does it already according to that patch
04:16:59 <bcos> Brnocrist: AMD doesn't speculatively fetch data from higher privilege, and is therefore immune to the problem PTI tries to solve
04:17:25 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
04:17:46 <Brnocrist> yeah
04:21:34 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
04:23:28 --- quit: hunterlabs (Ping timeout: 255 seconds)
04:25:45 --- join: uvgroovy (~uvgroovy@2601:184:4980:e75:5574:74af:c3ae:f99a) joined #osdev
04:27:07 --- quit: uvgroovy (Client Quit)
04:27:21 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-nfzkzscdoqgomnbh) joined #osdev
04:27:23 --- join: uvgroovy (~uvgroovy@2601:184:4980:e75:8cfc:6e9b:499a:4809) joined #osdev
04:27:31 --- join: zng (~zng@ool-18ba49be.dyn.optonline.net) joined #osdev
04:28:34 --- quit: Belxjander (Ping timeout: 240 seconds)
04:30:20 --- quit: immibis (Ping timeout: 240 seconds)
04:31:17 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
04:35:34 --- quit: sdfgsdfg (Ping timeout: 248 seconds)
04:35:39 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
04:43:57 --- quit: listenmore (Quit: Konversation terminated!)
04:59:00 --- quit: hunterlabs (Ping timeout: 265 seconds)
05:00:26 <froggey> doug16k: found yer problem: https://github.com/torvalds/linux/commit/a0c0feb57992c5caed170feab8a68c51306eb7c3
05:00:28 <bslsk05> ​github.com: KVM: x86: reserve bit 8 of non-leaf PDPEs and PML4Es in 64-bit mode o… · torvalds/linux@a0c0feb · GitHub
05:04:22 --- quit: Belxjander (Ping timeout: 248 seconds)
05:05:19 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-nqnypottgfmjafoz) joined #osdev
05:05:19 --- quit: caen23 (Read error: Connection reset by peer)
05:05:54 --- nick: clickjack -> immersive
05:06:36 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
05:09:47 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
05:10:12 --- quit: hunterlabs (Ping timeout: 252 seconds)
05:11:22 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-ulukoikcfeiobhno) joined #osdev
05:11:37 --- join: glauxosdever (~alex@ppp-94-64-152-176.home.otenet.gr) joined #osdev
05:12:41 --- quit: osa1 (Ping timeout: 256 seconds)
05:21:00 --- quit: zwliew (Quit: Connection closed for inactivity)
05:22:43 --- quit: Asu (Ping timeout: 260 seconds)
05:23:00 --- join: Asu (~sdelang@AMarseille-658-1-162-118.w86-198.abo.wanadoo.fr) joined #osdev
05:26:06 --- quit: hunterlabs (Ping timeout: 255 seconds)
05:28:20 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-whgrmhsdgdzuotnz) joined #osdev
05:41:06 --- join: tacco\unfoog (~tacco@dslb-188-104-222-056.188.104.pools.vodafone-ip.de) joined #osdev
05:41:47 --- join: hitchhikr (~hitchhikr@AAubervilliers-653-1-55-179.w90-61.abo.wanadoo.fr) joined #osdev
05:43:13 --- join: samathy (~samathy@cpc86036-nott19-2-0-cust178.12-2.cable.virginm.net) joined #osdev
05:49:55 --- quit: MarcinWieczorek (Quit: WeeChat 2.0.1)
05:51:13 --- quit: m3nt4L (Remote host closed the connection)
05:55:55 --- quit: uvgroovy (Quit: uvgroovy)
05:58:58 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-bpcfnzxrsbqcchky) joined #osdev
06:04:15 --- quit: hunterlabs (Ping timeout: 265 seconds)
06:07:57 --- join: uvgroovy (~uvgroovy@2601:184:4980:e75:31cf:9706:a30:187c) joined #osdev
06:08:59 --- join: lijero (~lijero@unaffiliated/lijero) joined #osdev
06:14:17 --- join: svk (~svk@port-92-203-4-24.dynamic.qsc.de) joined #osdev
06:15:40 --- quit: uvgroovy (Quit: uvgroovy)
06:21:06 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-cdkpjvssoqtekcef) joined #osdev
06:22:50 --- join: GautamS (~GautamS@59.182.251.4) joined #osdev
06:25:48 --- quit: daniele_athome (Ping timeout: 256 seconds)
06:27:49 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
06:27:50 --- quit: hunterlabs (Ping timeout: 246 seconds)
06:30:27 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-qygiluabmbmzxpgq) joined #osdev
06:35:31 --- join: uvgroovy (~uvgroovy@199.188.233.130) joined #osdev
06:35:32 --- join: hmmmm (~sdfgsf@pool-72-79-161-183.sctnpa.east.verizon.net) joined #osdev
06:35:34 --- quit: uvgroovy (Remote host closed the connection)
06:35:47 --- join: uvgroovy (~uvgroovy@199.188.233.130) joined #osdev
06:36:37 --- quit: uvgroovy (Client Quit)
06:37:46 --- join: uvgroovy (~uvgroovy@199.188.233.130) joined #osdev
06:38:23 --- quit: uvgroovy (Client Quit)
06:38:35 --- join: uvgroovy (~uvgroovy@199.188.233.130) joined #osdev
06:40:48 --- quit: hunterlabs (Ping timeout: 255 seconds)
06:41:45 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-twquxktxnhovfvdk) joined #osdev
06:46:19 --- join: Vercas-web (d920cbb2@gateway/web/freenode/ip.217.32.203.178) joined #osdev
06:47:25 <Vercas-web> So, about the dumpster fire of the day...
06:48:13 <Vercas-web> Does anyone know any source that could suggest kernel data can actually be read?
06:48:43 <Vercas-web> I've found only one blog post with the test, suggesting that the CPU actually zeroes out the register when the micro op fails.
06:48:57 <Vercas-web> Although it continues speculative execution. :l
06:58:23 --- quit: Belxjander (Ping timeout: 260 seconds)
07:05:15 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
07:05:23 --- quit: m_t (Quit: Leaving)
07:07:47 --- join: ingrix (ingrix@gateway/vpn/privateinternetaccess/ingrix) joined #osdev
07:08:48 --- quit: Love4Boobies (Quit: Leaving)
07:10:12 <bcos> Vercas-web: The CPU can't zero out an (architectural visible) register when a speculatively executed micro-op fails - would lead to a massive amount of buggy
07:10:20 --- quit: samathy (Ping timeout: 240 seconds)
07:11:18 <bcos> (but "no" - I haven't seen any reason for these people to care if an attacker figures virtual addresses kernel uses for anything)
07:11:46 <bcos> (...other than making "kernel address space randomisation" look more silly)
07:17:00 <Vercas-web> bcos: I didn't claim the CPU zeroed out an architecturally-visible register.
07:17:26 <Vercas-web> The interrupting instruction doesn't commit registers when it retires.
07:17:42 --- quit: hunterlabs (Ping timeout: 265 seconds)
07:18:05 <Vercas-web> KASLR gets borked every fortnight, this is nothing new.
07:18:24 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-njrejuzrifyljcae) joined #osdev
07:18:29 <Vercas-web> But both NT and Linux are getting fast-tracked patches right now.
07:18:33 <Vercas-web> So, something's on fire.
07:19:24 <Vercas-web> Whatever it is, Microsoft, Google, Amazon, etc. are working hard to mitigate.
07:19:32 <Vercas-web> NT is finally getting PCID support!
07:20:46 --- quit: navidr (Quit: Connection closed for inactivity)
07:20:52 <Vercas-web> Or, eh, scratch "support".
07:21:00 <Vercas-web> They seem to be making it mandatory.
07:23:08 --- join: listenmore (~strike@2.27.123.231) joined #osdev
07:24:32 <Vercas-web> Seeing them all moving kernel data out of the process's virtual address space is, honestly, a bit scary.
07:26:44 --- join: osa1 (~omer@212.252.142.116) joined #osdev
07:26:44 --- quit: osa1 (Changing host)
07:26:44 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
07:26:55 <GautamS> You mean to say, a lot of information that should be in kernel space was (till now) accessible to random programs?
07:27:27 --- quit: xenos1984 (Quit: Leaving.)
07:27:28 <Vercas-web> GautamS: Random, no.
07:27:30 <bcos> GautamS: No, just it's address
07:27:30 <Vercas-web> No way.
07:27:31 --- quit: hunterlabs (Ping timeout: 255 seconds)
07:27:46 <Vercas-web> And prolly still won't be, once we get all the info.
07:28:01 <Vercas-web> 98% sure that this bug is getting its own name, and a logo!
07:28:36 <GautamS> I'm probably out of the loop. What's the actual discussion about?
07:28:50 <Vercas-web> Intel CPUs have an odd bug.
07:28:54 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-gbxnvnfjqtyixlqm) joined #osdev
07:29:24 <Vercas-web> If you execute two instructions like this: mov rdi, SomeKernelAddress; mov rdi, [rdi + rcx + 0];
07:29:36 <bcos> Not sure it's fair to call it a bug - doesn't break documented behaviour or anything
07:29:37 <Vercas-web> Where RCX contains a userland address that is mapped.
07:30:12 <Vercas-web> Running this in userland has an odd behaviour with the speculative execution mechanism.
07:31:02 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
07:31:13 <Vercas-web> The first mov instruction fails. However, when the address is valid, the second instruction is also speculatively executed.
07:31:31 <Vercas-web> (valid as in mapped, just inaccessible to userland)
07:32:09 <Vercas-web> This second instruction gets weird. It uses RDI in address computation, which depends on the previous instruction's result... But it gets executed as if RDI = 0
07:32:29 <Vercas-web> So it ends up prefetching the memory address contained in RCX.
07:33:06 <Vercas-web> So you'll get a signal or vector exception from the first instruction.
07:33:25 <Vercas-web> But after that, you can access the memory address that was in RCX...
07:33:47 <GautamS> Ah, I see. And this seems to have been overlooked for a long time
07:33:51 <Vercas-web> And if it's cached (loads very quickly), then you know it was prefetched by speculative execution.
07:34:36 <Vercas-web> So, this breaks KASLR.
07:34:57 <Vercas-web> Because random kernel addresses can be poked.
07:35:05 <bcos> Mostly, with 2 memory accesses (where one fails) you can use "cache timing" to determine the difference between "not present page" and "present, supervisor" page; which is completely worthless information that should never create any kind of risk and nobody has any reason to care about
07:35:43 <Vercas-web> bcos: To be completely fair, it does help with one thing.
07:36:13 <Vercas-web> Making kernel developers' fuck ups harder to find.
07:36:28 <bcos> The funny part is that the kernel developers could have mapped a single page "everywhere" (so that nothing in kernel space is "not present"), and avoided a huge performance hit from PTI
07:36:47 <Vercas-web> bcos: Hah, that won't work.
07:36:58 <bcos> Why not?
07:37:07 <Vercas-web> It'll make it harder, but that one page will always hit in L2.
07:37:20 <Vercas-web> Actually.
07:37:24 <bcos> So set the PAT so it's uncached..
07:37:29 <Vercas-web> Yeah.
07:37:45 <Vercas-web> This is indeed a solution.
07:38:11 <Vercas-web> Now we gotta wait to find out why neither Microsoft nor Linus and friends(tm) didn't do this.
07:39:10 <bcos> I hope they don't do this - it makes AMD look better than Intel (for performance) and makes it easier for people like us to get better performance than Windows/Linux
07:39:11 <bcos> :-)
07:39:36 <Vercas-web> :D
07:39:40 <GautamS> haha
07:39:46 <bcos> Well, not like me - micro-kernel avoids the problem already.. :-)
07:39:58 <Vercas-web> Hah, same.
07:40:03 <bcos> :-)
07:40:25 <Vercas-web> However, my kernel will soon(tm) be copying data from userland into kernel.
07:40:35 <Vercas-web> And back.
07:40:51 <doug16k> froggey, commit message is wrong. it is only reserved in PML4e
07:40:54 <Vercas-web> For IPC. So any data in transit is still a target.
07:41:01 <doug16k> good find though
07:41:33 --- join: uvgroovy_ (~uvgroovy@199.188.233.130) joined #osdev
07:42:04 <svk> bcos, how would that help, kernel pages that are cached can still be distinguished from this page, or am i missing something?
07:42:12 <doug16k> I could backoff my workaround to only disable it in PML4e and PDPT. that would reduce the severity of the workaround by 512x
07:42:34 <Vercas-web> svk: TLB won't miss
07:42:54 --- quit: uvgroovy (Ping timeout: 255 seconds)
07:42:54 --- nick: uvgroovy_ -> uvgroovy
07:43:24 <bcos> svk: Could have a randomised mixture of cached and uncached if you wanted
07:43:49 <svk> hmm yeah that makes sense
07:44:34 --- quit: daniele_athome (Ping timeout: 240 seconds)
07:45:21 <Vercas-web> bcos: You know how intense memory operations use lots of memory bus bandwidth, and it can be heard through HAM radio?
07:45:30 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
07:45:56 <Vercas-web> It would be really interesting to try the instructions on an uncached-but-present kernel page.
07:45:58 --- quit: osa1 (Ping timeout: 248 seconds)
07:46:04 <Vercas-web> To see if a read is actually being performed.
07:46:14 --- quit: hunterlabs (Ping timeout: 246 seconds)
07:46:17 <doug16k> uncached reads are serializing
07:46:41 <doug16k> the cpu will stall until the reorder buffer is empty, then issue the uncached load
07:46:50 <Vercas-web> Wait, really?
07:46:59 <svk> this might be still vulnerable if you have an pipt/vipt cache no?
07:47:02 <Vercas-web> Then even more reason to test this.
07:47:17 <doug16k> uncached read is ultimate barrier
07:48:28 <Vercas-web> I feel like I should duct-tape together my own test code.
07:48:50 <Vercas-web> I can certainly make a driver to map an uncached page for me.
07:48:54 <Vercas-web> On Windows.
07:49:26 <bcos> Probably already have multiple drivers that map uncached (MMIO) pages
07:49:29 <doug16k> technically it won't know it is uncached immediately, but it will realize eventually and do the flush/stall
07:49:30 --- join: pictron (~tom@pool-173-79-33-247.washdc.fios.verizon.net) joined #osdev
07:49:39 <svk> write-through, no-allocate might work
07:49:42 <Vercas-web> bcos: The point is, I need one specific address to poke.
07:50:04 <Vercas-web> doug16k: It needs the TLBe, yes.
07:50:41 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
07:51:04 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-imqpnelcbyuhjwee) joined #osdev
07:52:28 <Vercas-web> bcos: Actually, I think I figured out why they don't map every page, haha.
07:52:49 <doug16k> Vercas-web, regular VirtualAlloc takes PAGE_NOCACHE as a flag
07:53:09 <Vercas-web> doug16k: Oh, neat.
07:53:59 --- quit: mquin (Quit: So Much For Subtlety)
07:54:15 --- join: samathy (~samathy@185.32.108.65) joined #osdev
07:55:33 <bcos> Vercas-web: "cat /proc/vmallocinfo" looks interesting..
07:57:10 <Vercas-web> bcos: 2^35 4-KiB pages to map, which requires 2.8 GB of paging tables. If you use 2-MiB pages, it's a bit better...
07:57:42 <Vercas-web> I don't have a Unix system here to check out /proc/vmallocinfo
07:58:19 <svk> Vercas-Web, point them all to the same PML4E should be 4*4KiB?
07:58:29 <bcos> It's mostly just a text file that display kernel addresses for everything that was allocated by "vmalloc()"
07:59:07 <Vercas-web> svk: Eh, good point.
07:59:12 <Vercas-web> bcos: I know.
07:59:36 --- quit: hunterlabs (Ping timeout: 252 seconds)
08:00:11 <Vercas-web> I should start tracking allocations in my kernel as well.
08:00:32 <Vercas-web> Might make my life easier in the future, eh?
08:01:00 <bcos> So that you can give user-space a nice convenient way to find out the virtual addresses kernel uses for a lot of things?
08:01:08 <bcos> :-0
08:01:35 --- join: multi_io_ (~olaf@x55b63ab2.dyn.telefonica.de) joined #osdev
08:02:10 <doug16k> 64% of the lines in my /proc/vmalloc are _do_fork, lol
08:02:27 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-xuwjoieqejaquybo) joined #osdev
08:02:56 <doug16k> vmallocinfo*
08:03:30 <doug16k> 1169 lines are _do_fork D:
08:04:00 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
08:04:38 --- quit: multi_io (Ping timeout: 248 seconds)
08:05:10 --- join: uvgroovy_ (~uvgroovy@199.188.233.130) joined #osdev
08:05:48 <Vercas-web> bcos: Not gonna let userland see any of that.
08:05:58 <Vercas-web> Just perhaps maaaaybe a kernel debugger.
08:06:03 <Vercas-web> Which I need to write... At some point.
08:06:20 <doug16k> do it. it's fun
08:06:28 --- join: tlaxkit (~hexchat@92.189.36.210) joined #osdev
08:07:13 --- quit: uvgroovy (Ping timeout: 256 seconds)
08:07:14 --- nick: uvgroovy_ -> uvgroovy
08:07:57 --- quit: bm371613 (Quit: Konversation terminated!)
08:08:39 --- join: MrOlsen (~reddawg@Pub.SpherePBX.com) joined #osdev
08:10:04 --- quit: Nach0z (Ping timeout: 256 seconds)
08:11:01 --- quit: zwliew (Quit: Connection closed for inactivity)
08:13:46 --- join: mquin_ (~mquin@freenode/staff/mquin) joined #osdev
08:15:57 --- join: Nach0z (~nach0z@c-24-126-182-195.hsd1.ga.comcast.net) joined #osdev
08:15:57 --- quit: Nach0z (Changing host)
08:15:57 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
08:18:46 <Vercas-web> doug16k: I know it'll be fun.
08:18:54 <Vercas-web> But first I've got another fire to put out, heh.
08:19:23 <Vercas-web> I have buttloads of data structures that I need to use in NASM, GAS, C and C++...
08:19:45 <Vercas-web> So I am writing a quick (but not dirty) Lua script to parse a data definition language.
08:20:13 <Vercas-web> To generate the structure definitions. Making sure that field offsets are identical.
08:21:10 --- quit: Nach0z (Ping timeout: 248 seconds)
08:21:15 <Vercas-web> I'm gonna be using this as a metalanguage for IPC later as well.
08:21:58 <Vercas-web> Gonna eventually add nice features like versioning.
08:22:30 --- quit: GautamS (Quit: Leaving)
08:23:26 --- nick: mquin_ -> mquin
08:24:48 --- nick: Asu -> Asu`afk
08:32:01 --- nick: Asu`afk -> Asu
08:36:34 --- quit: hunterlabs (Ping timeout: 240 seconds)
08:37:30 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-oncdfbyspwtcjauy) joined #osdev
08:38:48 --- quit: glauxosdever (Quit: leaving)
08:42:33 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:42:38 --- join: Nach0z (~nach0z@c-24-126-182-195.hsd1.ga.comcast.net) joined #osdev
08:42:38 --- quit: Nach0z (Changing host)
08:42:38 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
08:44:28 --- quit: hunterlabs (Ping timeout: 255 seconds)
08:45:34 --- quit: nzoueidi (Ping timeout: 250 seconds)
08:46:28 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-uvyrcfjvinvzwygw) joined #osdev
08:47:14 --- join: vaibhav (~vnagare@125.16.97.125) joined #osdev
08:56:49 --- join: mlq (~mlq@unaffiliated/mlq) joined #osdev
08:57:12 --- quit: Vercas-web (Ping timeout: 260 seconds)
09:01:38 --- quit: vaibhav (Ping timeout: 256 seconds)
09:06:12 --- join: osa1 (~omer@212.252.142.116) joined #osdev
09:06:12 --- quit: osa1 (Changing host)
09:06:12 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
09:07:57 --- quit: caen23 (Ping timeout: 252 seconds)
09:08:47 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:10:07 --- quit: hunterlabs (Ping timeout: 255 seconds)
09:11:31 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-fnyxonazwxbkaxfc) joined #osdev
09:13:41 --- join: Arcaelyx (~Arcaelyx@2601:646:c200:27a1:8c34:11a4:b6fb:69d7) joined #osdev
09:13:53 --- join: John__ (~John__@79.97.140.214) joined #osdev
09:18:21 --- join: GautamS (~GautamS@59.182.251.4) joined #osdev
09:18:34 --- join: gdh (~gdh@2605:a601:639:2c00:bd58:804:ca92:d320) joined #osdev
09:25:27 --- quit: svk (Quit: Leaving)
09:26:53 --- quit: unpacked (Remote host closed the connection)
09:27:09 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:27:41 --- quit: unpacked (Remote host closed the connection)
09:27:58 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:28:29 --- quit: unpacked (Remote host closed the connection)
09:28:48 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:29:19 --- quit: unpacked (Remote host closed the connection)
09:29:34 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:30:06 --- quit: unpacked (Remote host closed the connection)
09:30:23 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:30:26 <MrOlsen> How's everyone today
09:30:55 --- quit: unpacked (Remote host closed the connection)
09:31:13 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:31:42 --- quit: unpacked (Remote host closed the connection)
09:31:59 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:32:30 --- quit: unpacked (Remote host closed the connection)
09:32:46 --- join: navidr (uid112413@gateway/web/irccloud.com/x-lczfoikymvqrkrtp) joined #osdev
09:32:49 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:33:17 --- quit: unpacked (Remote host closed the connection)
09:33:33 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:34:05 --- quit: unpacked (Remote host closed the connection)
09:34:24 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:34:51 --- nick: kg -> k
09:34:53 --- quit: unpacked (Remote host closed the connection)
09:35:11 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:35:26 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
09:35:40 --- quit: unpacked (Remote host closed the connection)
09:36:00 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:36:31 --- quit: unpacked (Remote host closed the connection)
09:38:40 --- join: vaibhav (~vnagare@125.16.97.117) joined #osdev
09:40:57 --- quit: hunterlabs (Ping timeout: 252 seconds)
09:41:08 --- quit: caen23 (Ping timeout: 260 seconds)
09:42:32 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-zqitnimlcqvblcia) joined #osdev
09:46:20 --- join: ox6 (836bae30@gateway/web/cgi-irc/kiwiirc.com/ip.131.107.174.48) joined #osdev
09:48:43 --- quit: osa1 (Ping timeout: 264 seconds)
09:51:29 --- quit: samathy (Quit: WeeChat 2.0)
09:57:18 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
09:58:05 --- join: wcstok (~Me@c-71-197-192-147.hsd1.wa.comcast.net) joined #osdev
09:58:16 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
09:58:50 --- quit: listenmore (Quit: Konversation terminated!)
10:01:56 --- quit: unpacked (Remote host closed the connection)
10:02:13 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
10:02:43 --- quit: unpacked (Remote host closed the connection)
10:03:01 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
10:03:30 --- quit: unpacked (Remote host closed the connection)
10:04:06 --- join: unpacked (~unpacked@108.5.133.67) joined #osdev
10:04:18 --- quit: unpacked (Remote host closed the connection)
10:04:32 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
10:05:05 --- quit: unpacked (Remote host closed the connection)
10:05:23 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
10:05:53 --- quit: unpacked (Remote host closed the connection)
10:06:09 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
10:06:40 --- quit: unpacked (Remote host closed the connection)
10:06:56 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
10:07:27 --- quit: unpacked (Remote host closed the connection)
10:07:43 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
10:08:14 --- quit: unpacked (Remote host closed the connection)
10:08:21 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
10:08:31 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
10:09:04 --- quit: unpacked (Remote host closed the connection)
10:09:20 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
10:09:51 --- quit: unpacked (Remote host closed the connection)
10:10:08 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
10:10:38 --- quit: unpacked (Remote host closed the connection)
10:10:56 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
10:11:26 --- quit: unpacked (Remote host closed the connection)
10:11:37 --- quit: ox6 (Changing host)
10:11:37 --- join: ox6 (836bae30@unaffiliated/ox6) joined #osdev
10:11:37 --- quit: ox6 (Changing host)
10:11:37 --- join: ox6 (836bae30@gateway/web/cgi-irc/kiwiirc.com/ip.131.107.174.48) joined #osdev
10:12:21 --- join: kbw (~KeyboardW@173.168.167.248) joined #osdev
10:13:35 --- quit: lucebac (Remote host closed the connection)
10:14:28 --- quit: caen23 (Ping timeout: 272 seconds)
10:14:50 --- quit: oaken-source (Ping timeout: 240 seconds)
10:18:33 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
10:22:13 --- quit: hunterlabs (Ping timeout: 252 seconds)
10:23:54 --- quit: hitchhikr ()
10:24:35 --- join: lucebac (~lucebac@lucebac.net) joined #osdev
10:24:35 --- quit: lucebac (Changing host)
10:24:35 --- join: lucebac (~lucebac@unaffiliated/lucebac) joined #osdev
10:24:55 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-iwqvbnbtdfzbbckc) joined #osdev
10:28:38 --- quit: lucebac (Ping timeout: 248 seconds)
10:34:41 <MrOlsen> For anyone here who has implemented TLS in their OS, do you pre-allocate any structures if the binary doesn't have a TLS section? I am executing against a 3rd party dynamic linker and even though my binary doesn't have a TLS section it is calling _tls_get_addr which will segfault because I have nothing at %gs:0x0 and wasn't sure if the normal behaviour is to load it with a null terminator
10:40:43 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
10:41:00 --- quit: Salek (Read error: Connection reset by peer)
10:41:51 <nur> http://www.fysnet.net/osdesign_book_series.htm <- has anyone read these
10:41:52 <bslsk05> ​www.fysnet.net: Operating System Design Book Series
10:42:02 <nur> how good are they
10:44:50 --- quit: caen23 (Ping timeout: 240 seconds)
10:46:21 <doug16k> MrOlsen, you'd need to check the ABI spec to see if it is required. reading the pointer at %gs:0 might be a sneaky way of uniquely identifying a thread
10:46:55 <doug16k> %gs:0 is expected to be a pointer to the TLS that you can use without gs prefix
10:49:07 <doug16k> essentially, the qword at %gs:0 is the same value that is in gsbase
10:49:58 --- join: lucebac (~lucebac@lucebac.net) joined #osdev
10:49:58 --- quit: lucebac (Changing host)
10:49:58 --- join: lucebac (~lucebac@unaffiliated/lucebac) joined #osdev
10:50:22 --- nick: multi_io_ -> multi_io
10:54:08 <doug16k> oops, s/qword/dword. on x86_64, fs is the tls segment. on i386 gs is the tls segment
10:55:18 --- quit: lucebac (Ping timeout: 248 seconds)
10:55:46 <doug16k> MrOlsen, I did a quick search of the spec and I found no mention of it being optional. I think it is required
10:57:34 <MrOlsen> yes, I'm going to have to read it again, I see that the TLS should be initialized regardless
10:57:43 <MrOlsen> thanks
10:57:45 --- nick: regreg_ -> regreg
10:58:05 <MrOlsen> I've been toying with my kernel but I wrote it in 2002 and stopped toying with it in 2006
10:58:17 <MrOlsen> so the ELF ABI is a bit old
10:58:45 <geist> if you started writing it in 2002 my guess is it's 32bit? one thing you might want to do is start over and implement an x86-64 version
10:58:55 --- quit: osa1 (Ping timeout: 264 seconds)
10:58:58 <MrOlsen> yeah it is 32bit
10:59:08 <MrOlsen> i wanted to refresh it a bit so i can do an ARM port
10:59:27 <geist> though in the case of TLS it doesn't help too much, since both 32 and 64bit x86 use gs: as their method
10:59:59 <MrOlsen> yeah, I'll have to study it a bit more to get full grasp and then implement it
11:00:42 <MrOlsen> or not use a current libc and run really old apps :/
11:02:55 <MrOlsen> It's just one of those things, when I left off there was a little bit more to be completely self hosted. Then I stopped and now 11-12 years passed and there is so much more to do!
11:03:43 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
11:07:19 <Sjors> https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/
11:07:22 <bslsk05> ​www.reddit.com: Intel bug incoming : sysadmin
11:07:29 <Sjors> has this been mentioned here before?
11:07:43 <Kazinsal> Probably
11:08:38 <geist> yeah we were talking about at least the liux changes that seem to be trying to work aroun dit
11:08:48 <geist> but it's clear there's some sort of big hw bug
11:09:40 <Sjors> yeah
11:09:44 <Kazinsal> The NT changes are similar to the Linux ones looking at the changes in syscall mechanism
11:10:05 <Sjors> PTI is some feature where x86 optimistically dereferences memory?
11:10:08 <Kazinsal> Performance hit on heavily I/O dependent systems is going to absolutely blow
11:10:10 <Sjors> at least, Intel CPUs
11:10:42 <Sjors> https://twitter.com/pwnallthethings/status/947978927284383744
11:10:42 <bslsk05> ​twitter: <pwnallthethings> @Blouchtika try { ␤ MOV R, byte [R0-addr] ␤ CMP R, value ␤ JNZ _speculative_predict_false ; whether this is taken depends on the branch predictor ␤ MOV R1 [cache line N] ; speculative fill true ␤ _speculative_predict_false: ␤ } catch { ␤ check if cache line N is filled ␤ }
11:11:02 <Kazinsal> KPTI is Linux's term for excluding as much of the kernel's page tables from the user address space as possible by only mapping in a system call/interrupt trampoline
11:11:58 <Kazinsal> The trampoline maps in the rest of the kernel page tables, does the actual kernel work, then unmaps the kernel page tables and returns to user space
11:12:05 <Sjors> whoa
11:12:21 <Sjors> so on x86, upper memory would not be mapped at all except for this trampoline?
11:12:41 <geist> that's the solution. I think if you use PCID, which is a fairly new feature, you can mitigate the unmapping of the kernel
11:12:57 <Sjors> so this would imply the bug allows optimistic dereferencing of pages the current ring has no access to
11:13:06 <geist> that's what i read
11:13:08 <Sjors> and reading the results through some side-channel
11:13:13 <Sjors> probably
11:13:20 <Kazinsal> It effectively makes most of the kernel entirely invisible to user space but imparts minimum a couple hundred cycles to each kernel entry in the form of a "mini context switch" where the mapping happens
11:13:29 <geist> but i haven't gotten any sort of official disclosure on it from work, so dont ask
11:14:00 <geist> yah i think with PCID the mini-context-switch is basically just more code, and thus adds a bit of an effect to all syscalls
11:14:05 <geist> i think if you dont have PCID it's probably awful
11:14:25 <Kazinsal> Yeah
11:15:47 <geist> iirc PCID showed up around sandy bridge, and i think AMD picked it up, though apparently AMD is immune to the bug
11:15:47 <Sjors> most people talk about it as if the bug only occurs in a VM environment
11:15:49 <Kazinsal> I don't have any insider knowledge either so everything I know about this is based off prior art
11:16:33 <Kazinsal> My understanding is that it works outside of a VM environment but in a VM environment you have the potential for host-guest pollution
11:16:50 <Kazinsal> And that's worse than just one kernel/userspace being attacked
11:16:55 <geist> yeah so in a vm environment i dunno what the solution would be. disabling stackedpaging?
11:17:23 <Kazinsal> Maybe apply the same trampoline concept to vmexits
11:17:53 <Kazinsal> AMD's speculative execution is probably different enough that it doesn't have this issue
11:18:19 <geist> yeah or the permission check is in a slightly different part of the pipeline that catches it first
11:18:38 <Sjors> :D
11:18:40 <geist> interesting that ARM is rolling in a similar change, but could be in general just because KAISER
11:18:50 <geist> which was i think already in motion anyway since november or so
11:18:56 <Sjors> KAISER?
11:18:56 <Kazinsal> Yeah
11:19:27 <geist> and theoretically with the ASID stuff and the split page table, armv7+ is only minimally affected
11:19:30 <geist> except
11:19:37 <geist> for the same additional-code-in-the-syscall-path thing
11:20:00 --- quit: cbanu (Quit: WeeChat 1.4)
11:20:14 <geist> i think in general folks were already deciding that keeping the kernel mapped all the time w/x86 style page table based mmu is already a problem for KASLR
11:20:20 --- join: m_t (~m_t@p5DDA2D85.dip0.t-ipconnect.de) joined #osdev
11:20:23 <geist> since you can probe the kernel and figure out where it's mapped
11:21:29 <Kazinsal> Yeah, this all going mainline is a good sign that the kernel folks are no longer interested in kernel hardening being an optional thing
11:21:45 <geist> indeed
11:21:56 <Kazinsal> Especially since it's being backported into 4.14
11:28:39 --- join: floatleft (~floatleft@109-186-22-204.bb.netvision.net.il) joined #osdev
11:28:56 --- join: lucebac (~lucebac@unaffiliated/lucebac) joined #osdev
11:30:05 --- quit: quc (Remote host closed the connection)
11:30:22 --- join: quc (~quc@87.116.237.223) joined #osdev
11:32:31 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
11:33:22 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
11:33:43 --- quit: freakazoid0223 (Ping timeout: 264 seconds)
11:37:58 --- quit: unpacked (Ping timeout: 248 seconds)
11:41:09 <lava> the idea for KAISER was mentioned in a paper in mid-2016, the first version of the KAISER patch went online on May 4, 2017
11:51:20 <Kazinsal> I am having to explain x86 paging to a LOT of people today because of this flaw
11:51:24 <Kazinsal> Thanks a fucking bunch, Intel
11:52:51 --- quit: vaibhav (Remote host closed the connection)
11:55:02 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
11:55:10 --- join: vaibhav (~vnagare@125.16.97.115) joined #osdev
11:58:29 --- join: dbittman (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
11:58:55 --- quit: regreg (Ping timeout: 264 seconds)
12:00:01 <Sjors> Kazinsal: admit it, it's secretly nice to explain stuff ;)
12:00:41 --- join: raphaelsc (~utroz@187.114.6.255) joined #osdev
12:01:30 <ox6> lol
12:05:19 --- join: regreg (~regreg@85.121.54.224) joined #osdev
12:09:06 --- quit: regreg_ (Ping timeout: 272 seconds)

12:12:28 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
12:16:32 --- quit: vmlinuz (Quit: Leaving)
12:25:26 --- quit: daniele_athome (Ping timeout: 248 seconds)
12:26:30 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
12:27:24 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
12:37:36 --- join: xerpi (~xerpi@131.red-88-23-235.staticip.rima-tde.net) joined #osdev
12:38:24 --- quit: xerpi (Remote host closed the connection)
12:39:11 --- join: xerpi (~xerpi@88.23.235.131) joined #osdev
12:41:28 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
12:48:43 <_mjg> re this intel cpu flaw, anyone knows the actual impact?
12:49:18 <_mjg> is that just memory layout leak or a straight up ring0 execution?
12:50:02 --- join: hppavilion[1] (~dosgmowdo@rrcs-24-43-8-234.west.biz.rr.com) joined #osdev
12:50:24 --- nick: Asu -> Asu`afk
12:52:36 <Kazinsal> Seems like layout leak at this point
12:53:30 <clever> is it something like the timing of a pagefault due to reading kernel memory, revealing if it was mapped or unmapped kernel memory?
12:54:16 <Sjors> that would be pretty easily fixable, I guess
12:54:21 <Sjors> just map everything to a zero'ed out page
12:54:26 <Sjors> it's not that
12:55:39 <_mjg> i doubt linux would accept the perf hit just to save kaslr
12:55:45 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
12:56:01 <_mjg> which is why i suspect there is more to that, but there is no public info
12:56:47 <ox6> i think type 1 HVs are the concern
12:59:14 <Kazinsal> My baseless speculation: Linux kernel people will mainline the fix but make it a config option, mainstream distros will turn the config option off, rendering most people vulnerable but at no performance cost.
12:59:49 <_mjg> for laptops and whatnot, sure
13:00:22 <_mjg> funnier thing will be with service providers which probably can't afford the hit
13:01:02 <Kazinsal> I'm not sure what the NT kernel folks are going to do. My best guess is it'll be mainlined and set as a boot-time config option that's enabled by default on Server and on workstations running Hyper-V or Device Guard
13:02:49 <Kazinsal> Which would also mean "enabled by default on Enterprise" since Enterprise will use Hyper-V to enable VTLs and Secure Kernel
13:05:09 --- quit: kbw (Quit: Textual IRC Client: www.textualapp.com)
13:08:38 --- quit: quc (Ping timeout: 248 seconds)
13:11:24 --- join: glauxosdever (~alex@ppp-94-64-152-176.home.otenet.gr) joined #osdev
13:12:29 --- quit: Nach0z (Ping timeout: 265 seconds)
13:13:20 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
13:17:29 --- join: listenmore (~strike@2.27.123.231) joined #osdev
13:18:36 --- quit: floatleft (Ping timeout: 255 seconds)
13:20:46 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
13:21:26 --- join: floatleft (~floatleft@2.55.188.42) joined #osdev
13:25:07 --- quit: GautamS (Quit: Leaving)
13:25:08 --- quit: Nach0z (Ping timeout: 260 seconds)
13:30:06 --- nick: Asu`afk -> Asu
13:35:38 <sortie> I just downloaded a program from SourceForge. In binary package form. Compiled for my OS Sortix. Made entirely without my involvement.
13:36:58 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:37:28 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
13:38:02 <_mjg> but is sortix going to address the intel bug?
13:38:18 <_mjg> on a more serious note that's solid
13:38:48 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
13:38:56 <_mjg> although last time i checked, sortix was weirdly in the middle between a hello world os and a functional hobby os
13:39:12 <_mjg> but maybe i mixed it with some other stuff i was checking out
13:39:42 <sortie> If you'll excuse me for just a moment, I'll add a note to the Sortix installation manual that Sortix is only supposed to work correctly if your CPU has no gaping vulnerabilities
13:40:07 <sortie> I don't have any details on the vulnerability that's supposedly happening
13:40:39 <sortie> That is, I only know of internet rumors
13:40:47 <sortie> Seems serious though
13:41:34 <sortie> Doesn't seem to hard to do a similar fix once I have more information. It's not terribly important as Sortix has way worse issues at this time.
13:41:55 --- quit: Nach0z (Ping timeout: 255 seconds)
13:41:57 <sortie> _mjg: Sortix is currently between "oh hey it's installable and self-hosting" and "holy shit it can do *that*".
13:42:41 --- join: Nach0z (~nach0z@c-24-126-182-195.hsd1.ga.comcast.net) joined #osdev
13:42:41 --- quit: Nach0z (Changing host)
13:42:41 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
13:43:12 <sortie> _mjg: https://users-cs.au.dk/~sortie/sortix/screenshots/sortix-gui-tix-upgrade-ssh-localhost.png https://users-cs.au.dk/~sortie/sortix/screenshots/sortix-git-server-prototype.png https://users-cs.au.dk/~sortie/sortix/screenshots/sortix-httpd-prototype-irc.png https://users-cs.au.dk/~sortie/sortix/screenshots/sortix-gui-qemu-linux-live-cd-toaru.png
13:44:23 <mischief> sortie: is that openbsd httpd?
13:44:51 <Kazinsal> I've rather opted out of self-hosting because if GNU Plus Linux disappears and Araxes doesn't, the universe is all kinds of hosed
13:45:01 <sortie> mischief: It sure is.
13:45:23 <mischief> sortie: is it running unmodified with your compiler and system libraries?
13:46:15 <sortie> mischief: Couple patches here and there. 1408 line unified diff.
13:46:54 <_mjg> sortie: nice
13:46:57 --- join: GautamS (~GautamS@59.182.251.4) joined #osdev
13:47:34 --- quit: Nach0z (Ping timeout: 248 seconds)
13:48:38 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
13:48:48 --- join: StereoBucket (~StereoBuc@pppoe-46-239-19-160.teol.net) joined #osdev
13:51:25 --- join: oaken-source (~oaken-sou@p3E9D35CA.dip0.t-ipconnect.de) joined #osdev
13:52:54 --- quit: hppavilion[1] (Ping timeout: 248 seconds)
13:55:10 --- quit: Pessimist (Remote host closed the connection)
13:56:31 --- quit: Asu (Ping timeout: 265 seconds)
13:56:35 --- join: Asu` (~sdelang@80.12.63.198) joined #osdev
13:57:59 --- join: jmill (~textual@cpe-66-68-66-14.austin.res.rr.com) joined #osdev
13:59:34 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:59:53 <glauxosdever> sortie forgot to mention those at least three ELF parsers/decoders that support Sortix ABI. https://github.com/valarauca/elfdecode/blob/master/src/header/abi.rs https://github.com/valarauca/elrond/blob/master/src/header/abi.rs https://github.com/esbullington/elfonshelf/blob/master/src/lookup.rs
13:59:55 <bslsk05> ​github.com: elfdecode/abi.rs at master · valarauca/elfdecode · GitHub
13:59:56 <bslsk05> ​github.com: elrond/abi.rs at master · valarauca/elrond · GitHub
13:59:57 <bslsk05> ​github.com: elfonshelf/lookup.rs at master · esbullington/elfonshelf · GitHub
14:00:09 <glauxosdever> I was involved though..
14:00:28 <glauxosdever> ..through that half-boredom and half-trolling wikipedia edit on ELF... :p
14:00:42 <glauxosdever> (For those that know)
14:01:21 <sortie> I think you meant to put that in #osdev
14:01:41 <sortie> But yes, fun that people add whatever entries are in the wikipedia article to their source code
14:01:43 <glauxosdever> Am I not in #osdev?
14:02:30 --- quit: Belxjander (Ping timeout: 248 seconds)
14:02:35 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
14:03:36 --- quit: fujisan (Quit: Connection closed for inactivity)
14:04:39 <sortie> *#sortix
14:04:53 <glauxosdever> sortie: I think they were like "Wat is dat Sortix? Oh, let's google it. Oh, nice. A hobby OS."
14:05:14 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
14:05:33 <glauxosdever> "But since it is in wikipedia, it has to be worthwhile"
14:05:53 <sortie> https://xkcd.com/978/
14:05:53 <bslsk05> ​xkcd - Citogenesis
14:06:07 --- quit: John__ (Read error: Connection reset by peer)
14:06:35 <glauxosdever> sortie: How comes you always have a relevant xkcd to share?
14:06:44 <sortie> Normally
14:07:17 <glauxosdever> Ok, "Mr. Normally", could you find the "beautiful danse moves" one? It's the backcover of my maths book.
14:09:10 --- join: hppavilion[1] (~dosgmowdo@rrcs-24-43-8-234.west.biz.rr.com) joined #osdev
14:10:02 <sortie> glauxosdever: Give me a few lines from it so I can type it into google
14:10:20 <glauxosdever> sin cos tan crap
14:10:26 <sortie> Also copying an xkcd without attribution violates the xkcd license unless the author has an agreement with the Mr. Monroe
14:10:58 <sortie> https://xkcd.com/809/ ?
14:10:58 <bslsk05> ​xkcd - Los Alamos
14:11:18 <glauxosdever> Nope.
14:12:07 <glauxosdever> Unless it wasn't from xkcd?
14:12:14 <glauxosdever> https://iwastesomuchtime.com/42729
14:12:14 <bslsk05> ​iwastesomuchtime.com: Beautiful dance moves.
14:13:41 <glauxosdever> I had the impression it was..
14:14:00 --- join: Uityyy (~yaaic@2607:fb90:bdf:98:a9ec:8bd4:f490:c740) joined #osdev
14:16:32 --- join: Love4Boobies (~L4B@unaffiliated/l4b) joined #osdev
14:16:48 <_mjg> LOL o \o \o/ \o o <o <o> o> o DANCE
14:16:48 <_mjg> DANCE .|. |. | / X \ | <| <|> LOL
14:16:48 <_mjg> LOL / \ >\ /< >\ /< >\ /< >\ /< DANCE
14:16:51 <_mjg> #related
14:17:15 <sortie> Uh
14:17:23 <sortie> The president of SourceForge just tweeted me
14:17:32 <glauxosdever> lolwat
14:17:43 <sortie> https://twitter.com/loganabbott/status/948317045405487104
14:17:44 <bslsk05> ​twitter: <loganabbott> @sortiecat FYI my company acquired SourceForge in 2016 and have been improving significantly. No more bundled adware, all projects are scanned for malware, https downloads and project web hosting, & more. Big redesign coming soon too <arstechnica.com/information-te… https://t.co/mVikasNsyn>
14:17:57 <sortie> This seems automated.
14:18:30 --- quit: Belxjander (Ping timeout: 248 seconds)
14:18:44 <sortie> Yep automated
14:19:09 <ox6> lol
14:19:22 <Love4Boobies> You think he typed that out for you? :)
14:19:48 <Love4Boobies> Man, we can't lse sortie!
14:19:51 <Love4Boobies> lose*
14:19:56 <sortie> I like to think I am worth of the President of SourceForge's attention
14:20:24 <sortie> Little does he realize mass templated response are just bad and I'll quote RT it
14:21:08 <Love4Boobies> Remember when sourceforge was considered cool?
14:21:38 <Love4Boobies> I wonder which large projects still use SF as their primary repo.
14:21:51 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
14:22:59 <Love4Boobies> A lot of the ones listed there don't.
14:23:08 <Love4Boobies> E.g., the audacity web site points to github.
14:23:22 <_mjg> who ever liked sf?
14:23:30 <Love4Boobies> I'm pretty sure OpenCV does too.
14:23:44 <_mjg> ignoring ads, their download policy was utter crap
14:23:55 <Love4Boobies> _mjg, well, it was still better than nothing.
14:23:59 <_mjg> i almost always want the url so that i can download it somewhere else
14:24:16 --- quit: floatleft (Read error: Connection reset by peer)
14:24:31 <_mjg> well in that spirit cvs was better than nothing :-S
14:24:39 <Love4Boobies> It really was.
14:25:05 <Love4Boobies> Only the nutjob that is Linus would use tarballs instead of CVS or SVN.
14:25:09 --- join: floatleft (~floatleft@109-186-77-192.bb.netvision.net.il) joined #osdev
14:25:15 <Love4Boobies> Even RCS and SCCS are an improvement over tarballs.
14:25:25 <Love4Boobies> (I actually used SCCS a little bit.)
14:25:50 <_mjg> well cvs was indeed better than nothing, but it was still extreme crap
14:26:08 <_mjg> i esp. loved "branching"
14:27:11 <Love4Boobies> How was CVS branching different than SVN branching?
14:27:26 <Love4Boobies> The quotes suggests something weird was going on.
14:27:31 <Love4Boobies> suggest*
14:28:25 <Love4Boobies> I never used CVS to manage any of my projects, I've just read about it in the past and also used it to get other people's code.
14:29:13 <_mjg> there was no branching
14:29:20 <_mjg> so people invented unholy ways to do it anyway
14:29:42 --- quit: floatleft (Ping timeout: 248 seconds)
14:30:26 <_mjg> another luller was lack of commit atomicity - if you committed stuff to n different files, that's n commits
14:30:41 <_mjg> if you run into conflicts or whatever as you do it, well, you can gtfo
14:30:51 --- join: floatleft (~floatleft@2.55.188.42) joined #osdev
14:30:53 <_mjg> e.g. you are left with part of the tree updated
14:31:09 <_mjg> basically cvs was a hack on top of rcs unfit for shared work
14:31:18 --- quit: oaken-source (Ping timeout: 248 seconds)
14:34:48 --- quit: GautamS (Quit: Leaving)
14:40:20 --- join: immibis (~chatzilla@122-59-200-50.jetstream.xtra.co.nz) joined #osdev
14:41:20 --- quit: Belxjander (Ping timeout: 240 seconds)
14:42:18 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
14:45:14 --- quit: xerpi (Remote host closed the connection)
14:45:52 * Kazinsal grumbles and considers writing a dynamic linker
14:46:22 <glauxosdever> Kazinsal: If it's for ELF, make sure to include the 0x53 ABI value. :p
14:46:22 --- quit: inode (Quit: )
14:47:15 --- quit: Shamar (Quit: Lost terminal)
14:50:18 --- join: byte512 (~4096bits@78-73-63-6-no187.tbcn.telia.com) joined #osdev
14:51:00 --- quit: uvgroovy (Ping timeout: 268 seconds)
14:54:09 --- quit: Asu` (Quit: Konversation terminated!)
14:57:28 --- quit: hppavilion[1] (Ping timeout: 240 seconds)
14:57:46 --- quit: wgrant (Ping timeout: 252 seconds)
15:02:05 <Love4Boobies> _mjg, SCCS is a lot like that but slightly worse in that it's per-file version control.
15:02:20 <Love4Boobies> If you want to manage a whole project, you kind of have to build a system around it.
15:02:56 --- join: wgrant (~wgrant@ubuntu/member/wgrant) joined #osdev
15:03:40 <Love4Boobies> When I say "per file" I mean you basically have one repository per file.
15:03:50 <_mjg> cvs is per-file as well
15:04:00 <Love4Boobies> Ah
15:04:05 <Love4Boobies> I tought it was more like SVN.
15:04:11 <_mjg> no
15:04:45 <_mjg> svn is definitely a significant improvement over cvs
15:05:13 <_mjg> git is fine for me, unfortunately people have the tendency to do crazy merges
15:05:22 <_mjg> and bisect has no idea what to do with that
15:05:59 <Love4Boobies> Git is fine for the most part but it's not really fit for some kinds of projects.
15:06:20 <Love4Boobies> For instance, would not use it to create a multimedia thing (music or games or whatever).
15:06:26 <glauxosdever> Goodnight!
15:06:53 <Love4Boobies> The reason is that since it's distributed, you can't really lock files as you can with non-distributed version control.
15:07:19 <_mjg> fun fact: netbsd and openbsd still use cvs
15:07:24 --- quit: glauxosdever (Quit: leaving)
15:08:06 <Love4Boobies> If an artist is working on some 3D model or a sprite or whatever, they basically have to tell everyone "hey, don't touch that file until I'm done with it" and hope that everyone will be disciplined.
15:08:43 <_mjg> reminds me of a supposed deployment method back in the day, where devs had the prod dir mounted over samba
15:08:52 <_mjg> and would yell "i'm deploying"
15:08:59 <Love4Boobies> ll
15:09:00 <Love4Boobies> lol
15:09:33 <_mjg> sounds like a joke, but is totally believable given the company it supposedly was taking place
15:09:43 <_mjg> in(at?)
15:11:07 --- quit: sortie (Quit: Leaving)
15:15:02 --- join: John__ (~John__@79.97.140.214) joined #osdev
15:17:58 --- quit: xenos1984 (Quit: Leaving.)
15:18:07 --- quit: caen23 (Ping timeout: 252 seconds)
15:24:26 --- join: darkavengr (~darkaveng@82-69-52-137.dsl.in-addr.zen.co.uk) joined #osdev
15:24:29 <darkavengr> hi
15:31:16 --- quit: darkavengr (Quit: Ex-Chat)
15:32:26 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:34:15 --- join: return0e (~return0e@87-102-105-145.static.kcom.net.uk) joined #osdev
15:42:20 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
15:44:22 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
15:49:03 --- quit: caen23 (Ping timeout: 256 seconds)
15:50:53 --- join: bemeurer (~bemeurer@2804:14d:5ce0:9113:5533:47ff:12ea:1a3f) joined #osdev
15:52:56 --- quit: fnodeuser (Ping timeout: 265 seconds)
15:53:42 --- join: fnodeuser (~irssiuser@ppp-2-86-205-194.home.otenet.gr) joined #osdev
15:54:40 --- join: jmill (~textual@cpe-66-68-66-14.austin.res.rr.com) joined #osdev
15:58:22 --- quit: bemeurer (Quit: Leaving)
15:59:30 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
15:59:44 --- join: bemeurer (~bemeurer@2804:14d:5ce0:9113:5533:47ff:12ea:1a3f) joined #osdev
16:00:29 --- quit: m_t (Quit: Leaving)
16:00:29 <doug16k> I remember being terrified to touch cvs, one mistake and you're screwed
16:01:13 --- quit: navidr (Quit: Connection closed for inactivity)
16:03:31 <ox6> i have felt that way every time i have to learn a version control solution
16:03:38 <ox6> git, perforce
16:04:31 <ox6> team whatever for visual studio back in the day
16:04:54 --- quit: bemeurer (Quit: Leaving)
16:10:42 <garit> I wish one day i will have some project worthy of version control system
16:10:59 --- join: epony (~nym@77-85-135-215.ip.btc-net.bg) joined #osdev
16:12:04 --- quit: epony (Max SendQ exceeded)
16:12:17 --- quit: gdh (Quit: Leaving)
16:13:17 --- join: epony (~nym@77-85-135-215.ip.btc-net.bg) joined #osdev
16:13:42 <_mjg> ye i'm afraid to do stuff in svn to an extent
16:13:58 <_mjg> with git i know i'm safe as long as i don't git push --force
16:17:52 --- quit: vaibhav (Quit: Leaving)
16:21:46 --- quit: jmill (Quit: Textual IRC Client: www.textualapp.com)
16:23:06 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
16:29:04 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:29:42 --- quit: caen23 (Ping timeout: 248 seconds)
16:29:57 --- quit: Barrett (Read error: Connection reset by peer)
16:30:48 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
16:35:38 <jjuran> My 3D models are text files. :-)
16:42:08 --- join: KidBeta (~textual@220.244.156.86) joined #osdev
16:42:20 --- quit: KidBeta (Max SendQ exceeded)
16:43:24 --- quit: unpacked (Remote host closed the connection)
16:43:43 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:44:12 --- quit: unpacked (Remote host closed the connection)
16:44:27 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:44:59 --- quit: unpacked (Remote host closed the connection)
16:45:17 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:45:46 --- quit: unpacked (Remote host closed the connection)
16:46:02 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:46:33 --- quit: unpacked (Remote host closed the connection)
16:46:50 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:46:58 --- join: KidBeta (~textual@220-244-156-86.tpgi.com.au) joined #osdev
16:47:20 --- quit: unpacked (Remote host closed the connection)
16:47:38 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:48:07 --- quit: unpacked (Remote host closed the connection)
16:48:24 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:48:55 --- quit: unpacked (Remote host closed the connection)
16:49:10 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:49:43 --- quit: unpacked (Remote host closed the connection)
16:50:02 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:50:30 --- quit: unpacked (Remote host closed the connection)
16:50:49 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:51:03 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
16:51:18 --- quit: unpacked (Remote host closed the connection)
16:51:33 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:52:05 --- quit: unpacked (Remote host closed the connection)
16:52:22 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:52:53 --- quit: unpacked (Remote host closed the connection)
16:53:12 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:53:41 --- quit: unpacked (Remote host closed the connection)
16:53:56 --- quit: KidBeta (Changing host)
16:53:56 --- join: KidBeta (~textual@hpavc/kidbeta) joined #osdev
16:53:58 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:54:28 --- quit: unpacked (Remote host closed the connection)
16:54:47 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:55:04 --- quit: geordi (Remote host closed the connection)
16:55:16 --- quit: unpacked (Remote host closed the connection)
16:55:32 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:55:40 --- quit: Shamar (Quit: leaving)
16:56:04 --- quit: unpacked (Remote host closed the connection)
16:56:18 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:56:51 --- quit: unpacked (Remote host closed the connection)
16:57:07 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:57:39 --- quit: unpacked (Remote host closed the connection)
16:57:57 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:58:26 --- quit: unpacked (Remote host closed the connection)
16:58:42 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
16:59:14 --- quit: unpacked (Remote host closed the connection)
16:59:32 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:00:02 --- quit: unpacked (Remote host closed the connection)
17:00:16 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:00:49 --- quit: unpacked (Remote host closed the connection)
17:01:05 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:01:28 --- quit: awang (Ping timeout: 240 seconds)
17:01:37 --- quit: unpacked (Remote host closed the connection)
17:01:52 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:02:11 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
17:02:21 --- quit: wgrant (Ping timeout: 268 seconds)
17:02:24 --- quit: unpacked (Remote host closed the connection)
17:02:41 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:03:12 --- quit: unpacked (Remote host closed the connection)
17:03:30 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:04:00 --- quit: unpacked (Remote host closed the connection)
17:04:17 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:04:47 --- quit: unpacked (Remote host closed the connection)
17:05:06 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:05:35 --- quit: unpacked (Remote host closed the connection)
17:05:50 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:06:05 --- quit: StereoBucket (Read error: Connection reset by peer)
17:06:22 --- quit: unpacked (Remote host closed the connection)
17:06:37 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:06:43 --- quit: caen23 (Ping timeout: 264 seconds)
17:07:10 --- quit: unpacked (Remote host closed the connection)
17:07:26 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:07:58 --- quit: unpacked (Remote host closed the connection)
17:08:15 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:08:45 --- quit: unpacked (Remote host closed the connection)
17:09:02 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:09:33 --- quit: unpacked (Remote host closed the connection)
17:09:51 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:10:21 --- quit: unpacked (Remote host closed the connection)
17:10:29 --- join: godel (~gonzalo@96-251-231-201.fibertel.com.ar) joined #osdev
17:10:36 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:11:08 --- quit: unpacked (Remote host closed the connection)
17:11:26 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:11:57 --- quit: unpacked (Remote host closed the connection)
17:12:11 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:12:44 --- quit: unpacked (Remote host closed the connection)
17:13:01 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:13:32 --- quit: unpacked (Remote host closed the connection)
17:13:48 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:14:20 --- quit: unpacked (Remote host closed the connection)
17:14:36 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:15:07 --- quit: unpacked (Remote host closed the connection)
17:15:26 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:15:55 --- quit: unpacked (Remote host closed the connection)
17:16:13 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:16:43 --- quit: unpacked (Remote host closed the connection)
17:17:02 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:17:14 --- join: wgrant (~wgrant@ubuntu/member/wgrant) joined #osdev
17:17:30 --- quit: unpacked (Remote host closed the connection)
17:17:34 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:17:48 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:18:18 --- quit: unpacked (Remote host closed the connection)
17:18:35 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:19:05 --- quit: unpacked (Remote host closed the connection)
17:19:23 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:19:53 --- quit: unpacked (Remote host closed the connection)
17:20:08 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:20:40 --- quit: unpacked (Remote host closed the connection)
17:20:55 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:21:28 --- quit: unpacked (Remote host closed the connection)
17:21:45 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:22:15 --- quit: unpacked (Remote host closed the connection)
17:22:33 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:23:03 --- quit: unpacked (Remote host closed the connection)
17:23:19 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:23:51 --- quit: unpacked (Remote host closed the connection)
17:24:10 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:24:38 --- quit: unpacked (Remote host closed the connection)
17:24:56 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:25:26 --- quit: unpacked (Remote host closed the connection)
17:25:44 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:25:49 --- part: ryoshu left #osdev
17:25:57 <Barrett> this guy should get some vagina to do input/output instead of an irc channel
17:26:14 --- quit: unpacked (Remote host closed the connection)
17:26:33 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:27:02 --- quit: unpacked (Remote host closed the connection)
17:27:20 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:27:30 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
17:27:49 --- quit: unpacked (Remote host closed the connection)
17:28:06 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:28:10 --- mode: ChanServ set +o Mutabah
17:28:22 <Kazinsal> ah the ol' fix_your_connection
17:28:37 --- quit: unpacked (Remote host closed the connection)
17:28:37 --- mode: Mutabah set +b unpacked!unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net$##fix_your_connection
17:28:55 --- join: unpacked (~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net) joined #osdev
17:29:05 --- mode: Mutabah set +b unpacked!~unpacked@pool-108-5-133-67.nwrknj.fios.verizon.net$##fix_your_connection
17:29:25 --- quit: unpacked (Remote host closed the connection)
17:30:34 <meowrobot> it's not just unpacked. it's ~unpacked.
17:30:41 <meowrobot> not unpacked
17:30:45 <meowrobot> therefore packed
17:30:47 <Kazinsal> /home/unpacked/unpacked!
17:30:50 --- quit: ox6 (Ping timeout: 240 seconds)
17:30:59 <clever> lol
17:31:07 <Mutabah> meowrobot: Yeah, I saw that - hence the second attempt :D
17:33:05 --- quit: tacco\unfoog ()
17:33:59 <jjuran> Can you ban tea and ~tea at the same time?
17:35:40 --- join: fujisan (uid4207@gateway/web/irccloud.com/x-gppcofjsnmqpvjxi) joined #osdev
17:39:41 --- quit: Barrett (Quit: exit)
17:41:21 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
17:44:16 --- join: unpacked (~unpacked@108.5.133.67) joined #osdev
17:44:28 --- quit: unpacked (Remote host closed the connection)
17:46:10 <Shockk> jjuran: yes
17:46:36 <Shockk> you can set +b *!*@~?tea
17:46:39 --- join: unpacked (~unpacked@108.5.133.67) joined #osdev
17:46:46 <Mutabah> unpacked: Seriously? SERIOUSLY!
17:46:51 --- quit: unpacked (Remote host closed the connection)
17:47:12 <Mutabah> Oh, wait... what? same ip, but no reverse dns
17:47:25 --- mode: Mutabah set +b unpacked!~unpacked@*$##fix_your_connection
17:47:38 <Kazinsal> next thing you know it's going to end up being unpacked_
17:48:03 --- quit: caen23 (Ping timeout: 256 seconds)
18:04:23 --- quit: John__ (Read error: Connection reset by peer)
18:14:49 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
18:21:10 --- quit: caen23 (Ping timeout: 248 seconds)
18:22:56 --- quit: behalebabo (Remote host closed the connection)
18:23:10 --- join: behalebabo (~behalebab@unaffiliated/behalebabo) joined #osdev
18:24:44 --- quit: alphawarr1or (Quit: Connection closed for inactivity)
18:27:28 --- quit: because (Ping timeout: 240 seconds)
18:30:53 --- join: because (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
18:46:22 --- join: ox6 (836bae30@gateway/web/cgi-irc/kiwiirc.com/ip.131.107.174.48) joined #osdev
18:47:20 --- quit: ox6 (Changing host)
18:47:20 --- join: ox6 (836bae30@unaffiliated/ox6) joined #osdev
18:47:20 --- quit: ox6 (Changing host)
18:47:20 --- join: ox6 (836bae30@gateway/web/cgi-irc/kiwiirc.com/ip.131.107.174.48) joined #osdev
18:50:51 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
18:51:30 --- quit: jack_rabbit (Ping timeout: 268 seconds)
18:51:34 --- quit: daniele_athome (Ping timeout: 248 seconds)
18:52:32 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
18:55:55 --- quit: caen23 (Ping timeout: 264 seconds)
18:56:37 --- quit: ahrs (Remote host closed the connection)
18:57:47 --- join: ahrs (quassel@gateway/vpn/privateinternetaccess/ahrs) joined #osdev
18:59:30 --- quit: zng (Ping timeout: 265 seconds)
19:01:05 <promach__> For http://xillybus.com/doc/microblaze-fpga-core-api , what does it mean by "An advantage of asynchronous I/O is that the buffers allocated in the host's RAM effectively become an extension of the FIFO in the FPGA, since they begin to take data as soon as it arrives at the FIFO. So even though memory buffers in host's RAM are suitable for extending the FPGA's FIFO's depth, synchronous I/O can't allow this to
19:01:07 <bslsk05> ​xillybus.com: Xillybus FPGA IP Core's signal API | xillybus.com
19:01:07 <promach__> happen." ?
19:03:17 --- join: hppavilion[1] (~dosgmowdo@rrcs-24-43-8-234.west.biz.rr.com) joined #osdev
19:05:26 <Mutabah> promach__: Random question - How much programming expirence do you have?
19:05:35 <Mutabah> And how much searching of terms do you do?
19:06:59 <promach__> @Mutabah: https://www.reddit.com/r/compsci/comments/7jxp48/io_concept_blockingnonblocking_vs_syncasync/
19:07:00 <bslsk05> ​www.reddit.com: I/O Concept – Blocking/Non-Blocking VS Sync/Async : compsci
19:07:18 <ox6> lol breaking out the fabric
19:07:28 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
19:07:39 <promach__> I do not understand how asynchronous I/O allows FIFO depth extension
19:09:14 <ox6> bcuz the data doesn't have to be clocked in most likely, from skimming the article
19:09:27 <Mutabah> Beacuse the program logic doesn't have to manually move adata around
19:09:42 <Mutabah> as far as it's concerned, data magically goes from the input through the fifo to the DMA buffer
19:09:59 <ox6> i have no idea what this is, it sounds like it is a demo file illustrating clock domain transfer
19:10:01 <Love4Boobies> Man, gnome 3 is utter garbage. It feels like it was designed by people who should never be let in charge of designing.
19:11:57 <mischief> enjoying your open sores?
19:12:17 <_mjg> dude
19:12:23 <promach__> @Mutabah: thanks
19:12:49 <_mjg> Love4Boobies: have you given tiling wms an honest chance?
19:12:56 <_mjg> Love4Boobies: i3 is the typical go to wm
19:13:14 <Love4Boobies> No and I do not intend to. I know how they work and they don't seem like the kind of thing I'd be interested in using.
19:14:16 <_mjg> well, it is largely a matter of taste, but defo worth trying out
19:14:24 <_mjg> if you end up really not liking it, so be it
19:14:28 <_mjg> otherwise there is no going back
19:14:46 <Love4Boobies> Thinking of trying LXDE.
19:15:07 --- quit: Belxjander (Ping timeout: 264 seconds)
19:15:07 <_mjg> some bsd folks created "lumina"
19:15:15 <_mjg> apparently it works and is leightweight
19:16:27 <Love4Boobies> I like the idea of lightweight --- it's one of the things I've looked for. But, to be fair, my machines are quite beefy so there's probably no need for that.
19:17:00 <Love4Boobies> My biggest complaint about GNOME is that it's super inconsistent. Things are spread randomly all over the place.
19:17:14 <_mjg> i think the main advantage of lightewight is that there is less random shit getting into your way
19:17:30 <mischief> i like openbox nowadays
19:17:48 <mischief> shame about the config file though
19:18:06 <_mjg> i may install enlightenment for teh lulz
19:18:28 <_mjg> i remember how they could not release e17 for years, now i'm curious how they ended up
19:18:49 <_mjg> lul Desktop December - Enlightenment Review - What a disaster
19:18:57 <_mjg> https://www.youtube.com/watch?v=cCBatV86WPk
19:18:58 <bslsk05> ​'Desktop December - Enlightenment Review - What a disaster' by quidsup (00:06:03)
19:19:25 <Love4Boobies> How do you make Vim print the output of a process in the current buffer?
19:19:38 <Love4Boobies> I'm running m4 on a couple of files and want to get the output in my file.
19:19:45 <Love4Boobies> I know I did this before...
19:20:06 <geist> yeah that would be useful
19:20:47 <geist> way back in the Be days I used to use an editor that had a worksheet mode where you could have an open text document and if you hit enter on a line it ran it as a shell command
19:20:57 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
19:20:58 <geist> and then put the result in the lines immediately afterwards
19:21:01 <mischief> um..
19:21:04 <_mjg> sounds like acme
19:21:05 <geist> then you could ctrl-z to remove the result
19:21:07 <mischief> Love4Boobies: try :r !fortune
19:21:14 <mischief> (for a fortune in your buffer)
19:21:23 <Love4Boobies> Ah, the !
19:21:26 <geist> it was pretty handy, you could have a bunch of commands all ready to go
19:21:50 <promach__> async I/O also implements auto-flushing the FIFO, I suppose, @Mutabah ?
19:22:08 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
19:22:27 <Mutabah> I'd assume so
19:22:44 <Mutabah> (Note - there's no need to include the @)
19:23:02 --- quit: hppavilion[1] (Ping timeout: 248 seconds)
19:23:09 <Mutabah> Then again... meh. If it's what you do for everyone, go ahead
19:23:33 <Love4Boobies> mischief, thanks, man. That will save me quite some time.
19:28:20 --- quit: caen23 (Ping timeout: 240 seconds)
19:28:25 <_mjg> eh. my brilliant idea for an optimisation slows things down by few %
19:28:26 <_mjg> gj
19:29:19 <_mjg> interesting, openbsd: Due to a limitation of the current vm system (see uvm(9)), mapping descriptors PROT_WRITE without also specifying PROT_READ is useless (results in a segmentation fault when first accessing the mapping). This means that such descriptors must be opened with O_RDWR, which requires both read and write permissions on the underlying object.
19:30:23 <_mjg> also fun fact: openbsd still doesn ot have unified buffer cache, i.e. writes through mmaped areas are not immediately visible with read(2)
19:30:38 <_mjg> and similarly with write(2) vs read from mmapped area
19:31:58 <__pycache__> huh
19:32:17 <__pycache__> i'm reading through the kaiser patchset in the lkml
19:32:51 <__pycache__> and linux was apparently mapping its TSS R/W before these patches on amd64 (?!)
19:34:05 <Mutabah> You need to change the TSS on every task switch in some kernel models. I assume linux was doing that?
19:34:28 <__pycache__> maybe it should remap in kernel mode
19:34:36 <Mutabah> (In the simplest model, there's a kernel stack per thread - you need to update the ESP0 value for each task switch)
19:34:37 <__pycache__> which i assume is what it does now
19:35:17 <__pycache__> i think remapping as RW and then RO when the kernel's done is the best choice
19:35:40 <Mutabah> Who would be editing it?
19:35:42 <geist> hah, Forcefully Unmap Complete Kernel With Interrupt Trampolines
19:35:45 <__pycache__> kernel
19:35:52 <Mutabah> geist: Poetry
19:35:53 <__pycache__> geist: damn PC culture
19:36:15 <__pycache__> we could finally have a nice acronym for an exploit
19:36:25 <geist> yah
19:36:30 * __pycache__ shakes fist
19:37:09 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
19:37:18 <__pycache__> Mutabah: as far as i'm aware the tss is only there because the kernel's page tables are in the user address space, no?
19:38:10 <Mutabah> The TSS has to exist because it's what controls the CPU state when going to numerically lower rings
19:38:35 <__pycache__> i know
19:38:42 <geist> and you have to write to it
19:38:49 <geist> because kernel stack
19:38:56 <__pycache__> but the user code doesn't need to access it, only kernel does
19:39:07 <Mutabah> __pycache__: the CPU has to access it
19:39:14 <Mutabah> When switching from user to kernel mode
19:39:18 <Mutabah> So, it has to be mapped.
19:39:24 <__pycache__> hn
19:39:35 <__pycache__> it needs a vittual address
19:39:39 <__pycache__> got it
19:39:47 <geist> yah even with the tiny trampoline thing in FUCKWIT, presumably you need to have a TSS, GDT, and IDT in the trampoline
19:40:02 <Mutabah> I'm not 100% on the details of the recent issues... dont' they allow userland to read from kernel space? (not write)
19:40:27 <Mutabah> So the mitigations here are moving all sensitive information out of the global mappsings
19:40:41 <geist> yeah dunno
19:40:46 <__pycache__> then we could just map it RO during the process' timeshare, and when we get to the kernel, we remap is RW for setting up esp0 andsuch no?
19:40:49 <Mutabah> The per-thread stack isn't really sensitve...
19:40:57 <Mutabah> and write access doesn't matter at all
19:41:10 <__pycache__> Mutabah: on i386 it apparently does
19:41:11 <Mutabah> If the user can do a kernel-level arbitary write, it's game over already
19:41:33 <__pycache__> ah you meant that
19:41:36 <_mjg> there is thead_info at the end of the stack
19:41:50 <_mjg> unless they managed to finally remove it
19:42:43 <jjuran> geist: Sounds like MPW Shell.
19:44:29 --- quit: fujisan (Quit: Connection closed for inactivity)
19:45:25 <jjuran> About two decades ago, I was looking for an alternative to the CodeWarrior IDE, and I switched to MPW Shell. I was already familiar with Unix, and MPW’s take on running commands was not an improvement, IMHO.
19:46:56 <geist> yah most likely the Be thing was some sort of MPW clone
19:47:02 --- quit: jack_rabbit (Ping timeout: 248 seconds)
19:47:03 <jjuran> Whereas in a Unix shell you get a chronological history of command+output pairs, in MPW Shell you get the most recent revision of the command followed by the output of each version in *reverse* chronological order.
19:47:24 <geist> this was the Pe editor, iirc
19:47:27 <jjuran> Or, you got tired of that and learned to Undo after running and before editing, in which case you had only the most recent output.
19:47:45 --- quit: ox6 (Remote host closed the connection)
19:47:58 <geist> right
19:48:12 <jjuran> MPW so disappointed me that I wrote a replacement, MacRelix.
19:48:27 <geist> i do remember it was pretty convenient for just clicking on make and then having it open errors and whatnot
19:48:31 <jjuran> https://www.metamage.com/text/relix/origins.html
19:48:32 <bslsk05> ​www.metamage.com: MacRelix Origins
19:48:33 <geist> and you could ctrl-z away the results
19:48:45 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
19:49:20 <jjuran> I don’t know about Pe, but MPW’s Make didn’t (and couldn’t) actually run any build commands. It only printed out what the commands were.
19:49:28 <jjuran> You were supposed to select them all and hit Enter.
19:50:00 <geist> that's what I mean. with Pe it actually ran whatever you hit, as a shell command
19:50:10 <geist> and then the results were inserted into the worksheet in the next line
19:50:15 --- quit: jack_rabbit (Max SendQ exceeded)
19:50:27 <geist> so it was neat to have a bunch of common commands in the worksheet associated with the project
19:50:38 <jjuran> Right, my point was that MPW tools couldn’t exec other tools.
19:51:27 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
19:51:39 --- nick: variable -> constant
19:52:53 <jjuran> More generally, I think it’s an antipattern to mix code with the output of running that code. See also spreadsheets.
19:55:50 --- quit: caen23 (Ping timeout: 240 seconds)
20:00:27 <geist> yah
20:11:41 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
20:12:32 --- quit: jack_rabbit (Max SendQ exceeded)
20:13:40 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
20:17:58 --- quit: jack_rabbit (Ping timeout: 248 seconds)
20:18:58 --- quit: Belxjander (Ping timeout: 252 seconds)
20:22:41 --- join: osa1 (~omer@212.252.142.116) joined #osdev
20:22:41 --- quit: osa1 (Changing host)
20:22:41 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
20:23:00 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
20:24:14 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
20:28:37 --- quit: Uityyy (Remote host closed the connection)
20:29:20 --- quit: caen23 (Ping timeout: 240 seconds)
20:30:52 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
20:32:47 --- join: osa1_ (~omer@212.252.142.138) joined #osdev
20:34:19 --- quit: osa1 (Ping timeout: 264 seconds)
20:37:58 --- nick: osa1_ -> osa1
20:38:04 --- quit: osa1 (Changing host)
20:38:04 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
20:38:50 --- quit: jack_rabbit (Ping timeout: 240 seconds)
20:41:59 --- quit: osa1 (Remote host closed the connection)
20:50:04 --- quit: constant (Quit: Found 1 in /dev/zero)
20:51:40 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
20:53:11 --- join: uvgroovy (~uvgroovy@c-65-96-163-219.hsd1.ma.comcast.net) joined #osdev
20:55:15 --- quit: uvgroovy (Client Quit)
20:55:31 --- join: uvgroovy (~uvgroovy@2601:184:4980:e75:5574:74af:c3ae:f99a) joined #osdev
20:55:53 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
20:59:40 --- quit: uvgroovy (Client Quit)
20:59:56 --- quit: lijero (Remote host closed the connection)
21:00:43 --- quit: caen23 (Ping timeout: 256 seconds)
21:11:20 --- quit: pictron (Ping timeout: 248 seconds)
21:15:07 --- quit: jack_rabbit (Ping timeout: 264 seconds)
21:22:24 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:25:36 --- join: jack_rabbit (~jack_rabb@2601:240:8200:e1c0:fc7e:99a8:322d:5782) joined #osdev
21:26:20 --- quit: freakazoid0223_ (Quit: He who laughs last, thinks slowest)
21:28:42 --- join: oaken-source (~oaken-sou@p3E9D33F7.dip0.t-ipconnect.de) joined #osdev
21:32:23 --- join: bcos_ (~bcos@1.123.132.248) joined #osdev
21:34:07 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
21:35:31 --- quit: empy (Ping timeout: 264 seconds)
21:35:52 --- quit: bcos (Ping timeout: 256 seconds)
21:40:38 --- quit: caen23 (Ping timeout: 248 seconds)
21:41:27 <sigtau> so... how 'bout that page table isolation
21:44:07 * variable sends sigtau to a process
21:54:25 <jjuran> so much killing
21:55:04 --- join: Humble (~hchiramm@2405:204:d287:4ff8:970f:6a59:9da5:2f75) joined #osdev
21:56:25 --- join: xenos1984 (~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120) joined #osdev
22:05:04 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
22:09:20 --- quit: caen23 (Ping timeout: 240 seconds)
22:10:05 --- join: ExtremeUltraFMan (~fooman@37-136-8-54.rev.dnainternet.fi) joined #osdev
22:12:31 <Mutabah> I'd take a punt at this being a win for microkernels... assuming it's just read and not write problems
22:13:20 --- quit: FMan (Ping timeout: 265 seconds)
22:24:50 <bcos_> A win for AMD too :-)
22:25:02 <Mutabah> Yep
22:25:04 <bcos_> (and maybe ARM - not sure about that)
22:25:09 <Mutabah> Not long after the Ryzen release too
22:25:22 <Mutabah> Well.. aparently there's patches for ARM64, so maybe ARM has a similar issue?
22:25:53 <bcos_> Wouldn't surprise me if it's not just Intel - for performance optimisations it makes perfect sense
22:26:28 <Mutabah> Not checking the permissions until the instruction is retired?
22:26:42 <bcos_> (speculatively fetch based on speculatively fetched data to avoid stalls while permission checking happens in parallel without causing the fetches to be delayed)
22:26:57 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
22:29:15 <bcos_> Actually; could probably consider it a race - whether the permission check completes before or after a "later" instruction is speculatively executed
22:30:19 <Mutabah> Ooooh... I think I see how this works...
22:30:39 <variable> so, if this only breaks KASR and is just an info-leak
22:30:42 <variable> its really a meh bug
22:30:47 --- join: Pessimist (~Pessimist@78.62.89.218) joined #osdev
22:30:48 --- quit: Pessimist (Changing host)
22:30:48 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
22:30:56 <variable> but is anything new known since yesterday?
22:31:02 <Mutabah> read from kernel, act on that read, observe timing of a later access that would be cached if the kernel value was a certain value...
22:31:28 <Mutabah> variable: It's potentially an arbitary kernel information leak.
22:31:39 <variable> true
22:31:43 <Mutabah> Which can mean quite a lot of sensitive information
22:31:59 <bcos_> Sort of breaks KASR a little (but doesn't even completely break KASR - e.g. attacker knows if page is present or not present, but doesn't know what page contains or what page is used for)
22:33:12 --- join: abraxis (~abraxis@197.184.61.15) joined #osdev
22:33:46 <bcos_> http://www.osnews.com/thread?652441
22:33:47 <bslsk05> ​www.osnews.com: OSNews > Thread > "RE[2]: Overhyped" by Brendan
22:34:02 <bcos_> ^ my description of what the problem is
22:35:20 <variable> bcos_: sounds about right
22:37:11 <Mutabah> Just present/not-present doesn't sound bad enough for this hubhub
22:37:27 <Mutabah> I'd expect that what actually happens is that the loaded value isn't zero, it's the actual value
22:37:33 <variable> ooof
22:37:38 <variable> that'd be bad
22:37:46 <geist> right, what Mutabah said
22:37:48 <Mutabah> which can lead to different address accesses in point `c`
22:38:00 <Mutabah> Which can be detected by checking the two cache lines
22:38:02 <geist> i think folks have been able to probe kernel space and figure out which pages are mapped for a while now
22:38:14 <geist> same as you can probe user space by observing page table delays
22:38:26 <variable> I've seen this kind of hubhub over non-issues in the past
22:38:33 <geist> but actually getting info out of the kernel, that's completely different
22:38:35 <variable> geist: Mutabah: yeah, my undergrad research was the inverse of that
22:38:47 <variable> instead of probing to get informaiton
22:38:59 <variable> selective slowing other procceses without crossing priv bounadies
22:39:24 <Mutabah> Anyone know of modern devices which are read sensitive on MMIO? :D
22:39:33 <variable> how could I walk * my own * address space to cause another process to be slower
22:39:53 <variable> (I wanted to get into using all the adders/multipliers/etc. but ENOTIME)
22:39:53 <geist> probing to defeat ASLR and KASLR, ARM would be just as affected, because it has functionally an identical page table mechanism
22:40:04 <geist> vs, say, POWER/PPC or itanium
22:40:27 <geist> so that may be why arm is going ahead and doing the KAISER thing too
22:40:45 <geist> also with the ASID and and already split page table, it should be somewhat cheaper on arm
22:40:58 <geist> probably a fairly low to negligable performance hit, so why not
22:41:35 <geist> Mutabah: can't think of any off the top of my head, but generally speaking if there is something read sensitive, it's some sort of status registers
22:41:53 <geist> i think virtio has something like that, but i think it's in the pci config space, not in a mmio register in a BAR
22:43:03 <geist> hah i actuall yhave osnews locally blocked here on my firewall
22:43:20 <geist> it's mostly just full of thom talking about how fucked everyone but netherlands is, so i just blocked it
22:43:46 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
22:43:46 <geist> link to article + one line commentary about how bad it is
22:49:58 --- quit: caen23 (Ping timeout: 240 seconds)
22:50:30 --- quit: regreg (Ping timeout: 248 seconds)
23:01:05 --- join: empy (~l@c-24-56-245-159.customer.broadstripe.net) joined #osdev
23:01:05 --- quit: empy (Changing host)
23:01:05 --- join: empy (~l@unaffiliated/vlrvc2vy) joined #osdev
23:04:11 --- quit: Pessimist (Remote host closed the connection)
23:09:12 --- join: Kazinsal_ (~Kazinsal@unaffiliated/blacklightos) joined #osdev
23:10:17 --- join: quc (~quc@host-89-230-166-189.dynamic.mm.pl) joined #osdev
23:11:09 --- quit: KidBeta (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:11:30 --- quit: Kazinsal (Disconnected by services)
23:11:32 --- nick: Kazinsal_ -> Kazinsal
23:11:47 <Kazinsal> I think I've figured out what bugs me most about the KPTI/KAISER/mitigations commit
23:11:53 <Kazinsal> The comments in it are absolutely atrocious
23:12:24 <Kazinsal> They describe the failure states as "SYSRET will explode dangerously" and in the case of one Ryzen bug, "bad things happen"
23:12:32 <Kazinsal> Like come on Linux people I know your coding standards are better than that
23:13:09 <Kazinsal> If you're embargoed from saying what then don't comment it at all because someone's gonna look back at that code and see "bad things happen" and not know WTF you're talking about
23:16:00 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
23:16:29 <Kazinsal> Re-phrasing: use terminology other than "bad things happen"
23:17:14 <Kazinsal> Elsewhere in the comment it's already stated that the speculative fetching can roll off the end of the canonical address space, which is a failure state
23:17:19 <Mutabah> [redacted]
23:17:26 <Kazinsal> But "bad things happen" does not describe *what* the failure state is
23:18:22 <Kazinsal> Does it leak kernel data? Does it send Betty White nastygrams and goatse? Does it assert RESET?
23:19:48 <jjuran> “Here be dragons”
23:22:24 --- quit: caen23 (Ping timeout: 256 seconds)
23:22:41 <Kazinsal> When SYSRET explodes dangerously, do the voltage regulators on my motherboard fuse together and let 750 watts of sweet sweet direct current flow through my processor at twelve volts?
23:22:51 <Kazinsal> Or does it just triple fault
23:23:25 <Kazinsal> Or does it throw a general protection fault pointing at the beginning of the non-canonical address space?
23:23:28 <Mutabah> Nasal demons I'd guess
23:23:58 <wcstok> Maybe it's just a devious plot to put everyone into wild useless speculating mode, if so it's an unqualified success
23:29:15 --- join: KidBeta (~textual@220-244-156-86.tpgi.com.au) joined #osdev
23:29:19 <dbittman> the longest con, by intel. it's somehow a marketing ploy
23:32:22 <Kazinsal> That would be magical because regardless of whether or not it would be a marketing ploy, the solution most DCs will have to the problem of "30% performance loss in heavy I/O processes on Intel servers" is "buy more Intel servers"
23:32:43 <wcstok> Well played Intel, well played
23:33:03 <dbittman> "AMD isn't affected because we do more optimization, so we're better"
23:33:40 <Kazinsal> Phoronix compiled kernel 4.15-rc with and without the patch and did their standard Linux benchmarks on both
23:33:54 <Kazinsal> Surprise, in I/O heavy loads the patch hits like a fucking truck
23:34:24 <dbittman> is it compile-time-disable-able?
23:34:41 <Kazinsal> Nope!
23:34:51 <dbittman> :(
23:35:17 <Mutabah> The patch? I think it's a runtime option to disale
23:35:22 <Mutabah> (boot option)
23:35:23 <dbittman> ah, okay
23:35:26 <Kazinsal> Oh, that'd be nice
23:36:00 <Kazinsal> I was going to say "you could throw an ' && 0' into the check that sets X86_BUG_CPU_INSECURE
23:36:37 <variable> Kazinsal: will "always false condition" fail?
23:36:39 <variable> :-)
23:36:49 <grawity> afaik you can boot with 'nopti' instead
23:36:59 <variable> Kazinsal: also, its phorinix, do we trust their benchmarks at all?
23:37:30 <Kazinsal> I mean for Linux yeah their benchmarks are solid
23:37:48 <Kazinsal> I would not trust them to invent benchmarks for Windows'
23:39:17 <Kazinsal> Also they just mark AMD platforms as X86_BUG_CPU_INSECURE because ???
23:40:04 --- quit: quc (Remote host closed the connection)
23:40:06 <Mutabah> I thought that they weren't making AMD as needing that patch?
23:40:17 --- join: quc (~quc@host-89-230-166-189.dynamic.mm.pl) joined #osdev
23:40:24 <Kazinsal> The proposed commit excluded AMD
23:40:29 <Kazinsal> The actual commit did not exclude AMD
23:40:40 <Mutabah> Interesting...
23:40:52 <Mutabah> I'm looking forward to the lifting of the embargo
23:40:54 <Kazinsal> /* Assume for now that ALL x86 CPUs are insecure */
23:41:05 <dbittman> ha! more intel marketing ploy. they're in league with them!
23:41:33 <dbittman> yeah, I'm curious to read about the whole thing when it's revealed
23:42:35 <lava> kaiser for everyone :]
23:46:42 --- quit: glfernando (Ping timeout: 252 seconds)
23:47:02 --- join: inode (~inode@unaffiliated/inode) joined #osdev
23:55:45 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
23:58:44 --- join: glfernando (glfernando@nat/google/x-rhdnwhqroiowgsed) joined #osdev
23:59:59 --- log: ended osdev/18.01.02