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

Monday, 1 January 2018

00:00:00 --- log: started osdev/18.01.01
00:00:02 <variable> so its not a page fault
00:00:07 <variable> its a "page mistake"
00:00:27 <variable> or a "computer related accident"
00:01:29 <klange> happy little accidents
00:01:42 <doug16k> oh, EFER bit 11 must be set for execute disable too
00:01:46 <variable> klange: rob ross!
00:02:03 <doug16k> EFER=0000000000000d01
00:02:54 <doug16k> it's not a race. I got a false positive earlier. when it returns it faults again, and again, and again...
00:03:15 <doug16k> (I hacked it to retry on "reserved bit set" error code)
00:03:43 <variable> y?
00:04:07 <doug16k> because everything was valid
00:04:26 <dmh> 0x000000d0h
00:05:12 --- join: dude12312414 (None@gateway/shell/elitebnc/x-hotiatmhhbwxspxv) joined #osdev
00:05:30 <doug16k> this never happens on TCG. only KVM, btw
00:06:01 <variable> TCG ?
00:06:08 <doug16k> qemu emulation mode
00:06:14 <doug16k> i.e. non-kvm mode
00:06:24 <variable> omg, I am so glad I live in the world of virtual machines and emulators
00:06:41 * variable does not even own a serial cable
00:07:03 <izabera> get any piece of wire
00:07:04 <doug16k> I have serial debug log set up. good luck booting bare hardware without serial
00:07:05 <izabera> tadaaa
00:07:25 <Mutabah> doug16k: Timing race condition?
00:07:47 <doug16k> Mutabah, I thought so too, but wouldn't returning from the fault handler fix that?
00:08:03 <doug16k> it doesn't it infinite loops
00:08:49 <doug16k> I could explicitly flush that TLB entry I guess. I don't know how it got a bad entry though, all of my accesses to page tables are lock cmpxchg8b or xchg
00:09:37 <doug16k> I have mmap semantics - if you mmap on top of an existing mapping you get new pages - I free the old ones
00:09:53 <doug16k> but that never happens in practice
00:10:35 <doug16k> in any case, it's either the old valid pte or the new one
00:10:44 <doug16k> let me try adding an explicit invlpg there, to be sure
00:12:08 --- join: awang_ (~awang@weston-24.51.208.121.myacc.net) joined #osdev
00:13:42 <doug16k> invlpg has no effect
00:15:52 <variable> doug16k: I read that statement as 'invlpg never has any effect' and questioned everything I knew about x86
00:15:53 <dmh> ring in the new year with soul crushing bugs
00:16:08 <doug16k> variable, lol
00:16:56 <doug16k> ah! The return address is returning to a not-present page
00:17:05 <variable> lol
00:17:41 <doug16k> my mprotect is probably rampaging D:
00:18:54 <doug16k> I had a bug with my stacks, and I realized that it was not right and it wasn't hitting a guard page - so I put 4MB guards around all stacks, lol
00:19:20 <doug16k> bam, fixed in 2 minutes - and left giant guards
00:19:53 <doug16k> stacks are a pain in the ass
00:20:34 <doug16k> should be able to data breakpoint that PTE though...
00:20:40 <variable> doug16k: pringles are better
00:20:50 --- quit: Belxjander (Ping timeout: 240 seconds)
00:22:21 * doug16k eats some pringles
00:22:33 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:22:45 <variable> doug16k: please tell me the joke makes sense
00:22:54 <doug16k> it does. stacks
00:23:00 <variable> good
00:23:22 <variable> alternate joke
00:23:43 <variable> why are you doing XML processing
00:23:45 <variable> alternate joke: why did the chicken cross the road
00:23:58 <jjuran> rampaging instead of RAM-paging? :-)
00:24:09 <doug16k> :D
00:24:13 <doug16k> variable, why?
00:24:21 <variable> doug16k: no idea, ask the chicken
00:24:47 <doug16k> heard the guy with an alligator in the bar joke?
00:24:49 <fnodeuser> an invariable joke :P
00:25:01 <variable> no
00:25:19 <variable> doug16k: how do you tell the difference between an alligator and crocodile
00:25:49 <fnodeuser> CrocoGator OS :P
00:26:06 <variable> one you see in a while, the other you see later
00:26:30 <jjuran> That was my guess. :-)
00:26:43 <jjuran> (The crocodile says goodbye first)
00:26:52 <doug16k> a guy walks into a bar with an alligator. bartender says, "hey, you can't have that in here!" guy says, "don't worry, he's trained, watch". the guy opens the alligators mouth and puts his dick in there. he keeps it there for a good five minutes and says, "see? he's trained. anyone else want to try?"
00:26:59 <doug16k> A guy stumbles over and says, "Sure I'll try, but I don't think I can keep my mouth open that long"
00:27:25 <fnodeuser> ha! :P
00:27:45 <variable> a guy walks into a bar with an alligator
00:27:49 <variable> he says ouch
00:28:06 <vdamewood> why does the bar hav an alligator?
00:28:09 <vdamewood> have*
00:28:20 <variable> it was hungry??
00:32:57 <doug16k> vdamewood, sorry about the dangling participle :D
00:35:50 --- quit: osa1 (Ping timeout: 240 seconds)
00:39:16 --- join: empy (~l@c-24-56-245-159.customer.broadstripe.net) joined #osdev
00:39:16 --- quit: empy (Changing host)
00:39:16 --- join: empy (~l@unaffiliated/vlrvc2vy) joined #osdev
00:39:59 <geist> merph
00:46:14 --- quit: awang_ (Ping timeout: 248 seconds)
00:46:32 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
00:53:07 --- join: awang_ (~awang@weston-24.51.208.121.myacc.net) joined #osdev
00:54:07 --- quit: Belxjander (Ping timeout: 264 seconds)
00:56:06 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:57:20 --- quit: awang_ (Ping timeout: 240 seconds)
00:59:58 --- quit: Guest90480 (Ping timeout: 240 seconds)
01:05:09 --- quit: regreg (Ping timeout: 252 seconds)
01:09:43 --- join: xerpi (~xerpi@88.23.235.32) joined #osdev
01:10:08 --- quit: xerpi (Remote host closed the connection)
01:10:41 --- join: xerpi (~xerpi@32.red-88-23-235.staticip.rima-tde.net) joined #osdev
01:20:33 --- quit: Belxjander (Ping timeout: 252 seconds)
01:22:37 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:25:29 --- join: awang_ (~awang@weston-24.51.208.121.myacc.net) joined #osdev
01:26:15 --- join: m_t (~m_t@p5DDA3201.dip0.t-ipconnect.de) joined #osdev
01:29:57 --- quit: awang_ (Ping timeout: 240 seconds)
01:37:19 --- quit: Belxjander (Ping timeout: 264 seconds)
01:40:31 --- join: Asu (~sdelang@AMarseille-658-1-164-49.w86-198.abo.wanadoo.fr) joined #osdev
01:42:52 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:47:16 --- quit: hmmmm (Remote host closed the connection)
01:50:12 --- quit: koyaan (Remote host closed the connection)
01:50:42 --- join: regreg (~regreg@85.121.54.224) joined #osdev
01:55:44 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
02:04:23 --- join: awang_ (~awang@weston-24.51.208.121.myacc.net) joined #osdev
02:07:40 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-mhvegqjqoryrfqob) joined #osdev
02:10:00 --- quit: immibis (Ping timeout: 248 seconds)
02:19:55 --- quit: Belxjander (Ping timeout: 264 seconds)
02:21:39 --- join: glauxosdever (~alex@ppp-94-66-38-249.home.otenet.gr) joined #osdev
02:21:41 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
02:22:18 --- quit: variable (Quit: /dev/null is full)
02:27:43 --- quit: floatleft (Ping timeout: 264 seconds)
02:29:01 --- join: floatleft (~floatleft@2.55.189.47) joined #osdev
02:33:26 --- quit: awang_ (Ping timeout: 248 seconds)
02:36:07 --- quit: Belxjander (Ping timeout: 264 seconds)
02:38:18 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
02:39:03 --- join: awang_ (~awang@weston-24.51.208.121.myacc.net) joined #osdev
02:39:24 --- quit: _sfiguser (Remote host closed the connection)
02:40:54 --- quit: daniele_athome (Ping timeout: 248 seconds)
02:41:43 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
02:43:34 --- quit: awang_ (Ping timeout: 248 seconds)
02:46:59 --- quit: king_idiot (Remote host closed the connection)
02:47:13 --- quit: xerpi (Remote host closed the connection)
02:50:31 --- quit: SM0TVI (Ping timeout: 264 seconds)
02:52:45 --- join: awang_ (~awang@weston-24.51.208.121.myacc.net) joined #osdev
02:55:50 --- quit: Belxjander (Ping timeout: 248 seconds)
02:56:44 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
02:57:36 --- quit: awang_ (Ping timeout: 268 seconds)
03:01:12 --- quit: caen23 (Ping timeout: 252 seconds)
03:03:27 --- quit: floatleft (Ping timeout: 240 seconds)
03:06:51 --- quit: Belxjander (Ping timeout: 268 seconds)
03:08:11 --- join: floatleft (~floatleft@2.55.50.189) joined #osdev
03:08:45 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
03:09:11 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
03:11:21 --- join: SM0TVI (~sm0tvi@unaffiliated/sm0tvi) joined #osdev
03:14:01 --- join: awang_ (~awang@weston-24.51.208.121.myacc.net) joined #osdev
03:18:48 --- quit: awang_ (Ping timeout: 252 seconds)
03:19:58 --- quit: regreg (Ping timeout: 260 seconds)
03:26:24 --- quit: Belxjander (Ping timeout: 272 seconds)
03:27:55 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
03:34:10 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
03:40:12 --- nick: Asu -> Asu`afk
03:42:34 --- quit: SM0TVI (Read error: Connection reset by peer)
03:45:07 --- join: awang_ (~awang@weston-24.51.208.121.myacc.net) joined #osdev
03:47:53 --- join: grzesiek (~grzesiek@PC-77-46-101-67.euro-net.pl) joined #osdev
03:48:54 --- join: SM0TVI (~sm0tvi@unaffiliated/sm0tvi) joined #osdev
03:56:06 --- join: regreg (~regreg@85.121.54.224) joined #osdev
03:58:50 --- quit: Belxjander (Ping timeout: 240 seconds)
04:05:26 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
04:07:31 --- join: zng (~zng@ool-18ba49be.dyn.optonline.net) joined #osdev
04:10:05 --- quit: quc (Remote host closed the connection)
04:10:18 --- join: quc (~quc@87.116.230.61) joined #osdev
04:19:19 --- quit: awang_ (Ping timeout: 264 seconds)
04:21:12 --- quit: sdfgsdfg (Ping timeout: 248 seconds)
04:26:32 --- join: awang_ (~awang@weston-24.51.208.121.myacc.net) joined #osdev
04:29:39 --- quit: Belxjander (Ping timeout: 265 seconds)
04:30:51 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
04:31:20 --- quit: awang_ (Ping timeout: 268 seconds)
04:40:55 --- quit: osa1 (Ping timeout: 248 seconds)
04:42:53 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
04:46:57 --- nick: Asu`afk -> Asu
04:54:35 --- join: martm (~bee@9225-7230-b3e5-2d93-4980-8309-07d0-2001.dyn.estpak.ee) joined #osdev
04:57:48 --- join: Guest90480 (~c@171.117.129.97) joined #osdev
05:00:05 --- quit: quc (Remote host closed the connection)
05:00:17 --- join: quc (~quc@87.116.230.61) joined #osdev
05:09:58 --- quit: Guest90480 (Quit: Guest90480)
05:16:21 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
05:16:44 --- quit: martm (Ping timeout: 250 seconds)
05:21:00 --- join: thinkpol (~thinkpol@users-1190.st.net.au.dk) joined #osdev
05:28:42 --- quit: ahrs (K-Lined)
05:28:54 --- join: martm (~bee@6e56-55d1-fe73-64bd-4980-8309-07d0-2001.dyn.estpak.ee) joined #osdev
05:30:02 --- join: ahrs (~quassel@gateway/vpn/privateinternetaccess/ahrs) joined #osdev
05:30:05 --- quit: martm (Client Quit)
05:37:00 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
05:37:30 --- join: awang_ (~awang@weston-24.51.208.121.myacc.net) joined #osdev
05:40:07 --- quit: regreg (Ping timeout: 248 seconds)
05:40:46 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
05:42:12 --- join: clickjac_ (~clickjack@kite.riseup.net) joined #osdev
05:43:15 --- nick: clickjac_ -> impertinente
05:43:28 --- quit: clickjack (Ping timeout: 252 seconds)
05:58:12 --- join: c_ (~c@171.117.129.97) joined #osdev
05:58:23 --- nick: c_ -> Guest62040
05:59:40 --- quit: Belxjander (Ping timeout: 272 seconds)
05:59:59 --- quit: Guest62040 (Read error: Connection reset by peer)
06:05:11 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
06:06:05 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
06:09:51 --- quit: hunterlabs (Ping timeout: 252 seconds)
06:12:38 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-dhwileatmsfqggqq) joined #osdev
06:14:50 --- quit: awang_ (Ping timeout: 240 seconds)
06:15:28 --- join: fujisan (uid4207@gateway/web/irccloud.com/x-ygwdekihlkbuspvd) joined #osdev
06:17:24 --- quit: hunterlabs (Ping timeout: 250 seconds)
06:17:39 --- nick: roxfan2 -> roxfan
06:23:05 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-ywmtnqmzhrncxoru) joined #osdev
06:25:49 --- quit: Halofreak1990 (Ping timeout: 252 seconds)
06:25:59 --- quit: daniele_athome (Ping timeout: 248 seconds)
06:26:47 --- quit: zwliew (Quit: Connection closed for inactivity)
06:27:04 --- join: cbanu (~cbanu@84.117.206.147) joined #osdev
06:27:35 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
06:27:46 <m712> uint8_t(* main_return_things)() = uint8_t todolambda(void){
06:27:48 <m712> whelp
06:27:52 <m712> that's not how it works
06:28:03 --- quit: listenmore (Remote host closed the connection)
06:28:04 <m712> nice try though IR
06:28:05 <m712> nice try
06:28:33 <m712> do i have to special case that
06:28:36 --- join: listenmore (~strike@2.27.123.231) joined #osdev
06:29:45 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
06:35:57 --- quit: listenmore (Remote host closed the connection)
06:36:29 --- join: listenmore (~strike@2.27.123.231) joined #osdev
06:38:13 --- join: svk (~svk@port-92-203-25-16.dynamic.qsc.de) joined #osdev
06:40:35 --- nick: regreg_ -> regreg
06:40:48 --- join: awang_ (~awang@weston-24.51.208.121.myacc.net) joined #osdev
06:41:34 <_mjg> char *message = malloc (sizeof (256 * 10));
06:45:07 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
06:45:43 --- quit: awang_ (Ping timeout: 264 seconds)
06:46:00 <m712> uint8_t(* main_ptr)() = main_return_things;
06:46:05 <m712> this needed a lot of hacks
06:46:07 <m712> i don't like my code
06:50:18 --- join: John__ (~John__@79.97.140.214) joined #osdev
06:52:07 --- quit: sortie (Quit: Leaving)
06:52:28 --- quit: thinkpol (Remote host closed the connection)
06:52:42 --- join: thinkpol (~thinkpol@users-1190.st.net.au.dk) joined #osdev
06:55:15 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
06:56:04 --- part: m712 left #osdev
07:01:53 --- quit: listenmore (Remote host closed the connection)
07:02:18 --- join: listenmore (~strike@2.27.123.231) joined #osdev
07:03:01 --- quit: m_t (Quit: Leaving)
07:03:07 --- quit: John__ (Read error: Connection reset by peer)
07:05:32 --- quit: mniip (Ping timeout: 272 seconds)
07:06:21 --- quit: listenmore (Remote host closed the connection)
07:06:57 --- join: listenmore (~strike@2.27.123.231) joined #osdev
07:10:26 --- join: John__ (~John__@79.97.140.214) joined #osdev
07:10:59 --- quit: listenmore (Remote host closed the connection)
07:11:35 --- join: listenmore (~strike@2.27.123.231) joined #osdev
07:13:39 --- quit: jack_rabbit (Ping timeout: 252 seconds)
07:19:06 --- quit: John__ (Read error: Connection reset by peer)
07:22:51 --- quit: listenmore (Remote host closed the connection)
07:23:22 --- join: listenmore (~strike@2.27.123.231) joined #osdev
07:24:06 --- quit: garit2 (Ping timeout: 248 seconds)
07:38:56 --- join: mniip (mniip@unaffiliated/mniip) joined #osdev
07:41:34 --- join: sham1 (~sham1@dsl-tkubng22-58c1f8-5.dhcp.inet.fi) joined #osdev
07:43:53 --- quit: listenmore (Remote host closed the connection)
07:44:20 --- join: listenmore (~strike@2.27.123.231) joined #osdev
07:47:38 --- join: Alexandre1er672 (~imdqfcf@201-50-179-173.user.veloxzone.com.br) joined #osdev
07:47:39 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)nszrbnzehg: cbanu Barrett fujisan ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

07:47:44 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)lizksqto: atk Guest88172 kasumi-owari ▄▄▄▄▄▄▄▄▄▄▄▄▄▄

07:47:50 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)spoud: vdamewood daniele_athome Barrett ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

07:47:55 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)zjktxb: Belxjander ampotos_ kasumi-owari ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
07:47:59 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)pjvlurdy: Belxjander impertinente atk ▄▄▄▄▄▄▄▄▄▄▄

07:48:04 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)rzbuc: qeos|2 babyflakes Belxjander ▄▄▄▄▄▄▄▄▄▄▄

07:48:09 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)lrmqondxo: caen23 ampotos_ oaken-source ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

07:48:14 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)sswhej: Guest88172 xenos1984 Burgundy ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

07:48:19 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)jjvztovyx: xenos1984 daniele_athome caen23 ▄▄▄▄▄▄▄▄▄▄

07:48:24 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)mirlnk: Belxjander ahrs sortie ▄▄▄▄▄▄▄▄▄▄

07:48:24 --- quit: listenmore (Remote host closed the connection)
07:48:29 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)otyad: hunterlabs Asu Barrett ▄▄▄▄▄▄▄▄▄▄

07:48:34 <Alexandre1er672> ▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)vnclldgjsd: Retr0id listenmore Asu ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

07:48:35 --- mode: ChanServ set +o sortie
07:48:36 --- kick: Alexandre1er672 was kicked by sortie (Alexandre1er672)
07:48:53 --- join: listenmore (~strike@2.27.123.231) joined #osdev
07:50:01 --- join: garit (~garit@unaffiliated/garit) joined #osdev
07:56:00 --- join: mquin (~mquin@freenode/staff/mquin) joined #osdev
07:58:19 --- quit: Zerith (Ping timeout: 264 seconds)
07:59:35 <sham1> Welp
08:01:26 --- join: multi_io_ (~olaf@x4db3409c.dyn.telefonica.de) joined #osdev
08:05:19 --- quit: multi_io (Ping timeout: 268 seconds)
08:11:34 --- quit: svk (Ping timeout: 248 seconds)
08:16:50 --- quit: Pessimist (Ping timeout: 240 seconds)
08:19:51 --- join: hmmmm (~sdfgsf@pool-72-79-161-183.sctnpa.east.verizon.net) joined #osdev
08:20:38 <izabera> what are the odds that my new headset runs linux?
08:21:02 <izabera> a super stripped down version of linux
08:22:22 <izabera> like, if you were building a new product that needs to talk over bluetooth, light up a couple of leds, do some power management and play audio, would you write the os from scratch?
08:22:34 <izabera> well, you == reasonable people
08:22:52 <izabera> this chan is probably not the best place for such a question
08:22:54 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
08:24:04 <renopt> I doubt it, but if they did use linux they'd have to publish the license and source somewhere
08:26:27 <renopt> the cost of hardware is much more relevent with low-margin things like headsets, too
08:27:07 --- quit: Belxjander (Ping timeout: 264 seconds)
08:27:29 <renopt> if they can save $0.50 by using minimal hardware vs. a full-featured SoC capable of running linux
08:27:56 <renopt> over some 10-100s of thousands of units, that adds up to a good bit
08:28:35 <izabera> i dunno, you don't actually need that much to run linux
08:28:47 <izabera> people run it without an mmu
08:31:16 <renopt> still way more than you need to interface with bluetooth and a few leds, it's probably just an arm cortex-M with an integrated bluetooth controller of some sort
08:31:45 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
08:31:48 --- quit: hunterlabs (Ping timeout: 265 seconds)
08:33:15 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-pcvvwqmmaglyzqsi) joined #osdev
08:34:12 --- join: freakazoid0223 (~IceChat9@108.52.4.148) joined #osdev
08:36:55 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
08:40:54 --- quit: Belxjander (Ping timeout: 248 seconds)
08:42:55 --- quit: hunterlabs (Ping timeout: 265 seconds)
08:44:20 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-lmcyeptmuhrvwqyl) joined #osdev
08:44:29 --- join: wcstok (~Me@c-71-197-192-147.hsd1.wa.comcast.net) joined #osdev
08:47:27 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
08:48:59 --- join: gdh (~gdh@2605:a601:639:2c00:cd9e:f508:fe04:237f) joined #osdev
08:48:59 --- quit: gdh (Client Quit)
08:50:45 --- join: vaibhav (~vnagare@125.16.97.124) joined #osdev
09:04:07 --- join: moondeck (~moondeck@185.143.254.252) joined #osdev
09:04:11 <moondeck> hey people
09:04:16 <moondeck> long time no see
09:04:37 <moondeck> anyone getting issues on github from that floppy dude?
09:05:03 <moondeck> https://github.com/moondeck/hydrogen/issues/1
09:05:04 <bslsk05> ​github.com: Could Hydrogen OS fit on a floppy? · Issue #1 · moondeck/hydrogen · GitHub
09:05:29 <moondeck> not sure if he is for real or just some elaborate OS troll
09:05:44 --- join: tacco\unfoog (~tacco@dslb-188-104-222-061.188.104.pools.vodafone-ip.de) joined #osdev
09:07:32 --- join: pictron (~tom@pool-173-79-33-247.washdc.fios.verizon.net) joined #osdev
09:13:58 --- quit: regreg (Ping timeout: 248 seconds)
09:16:29 --- join: svk (~svk@port-92-203-25-16.dynamic.qsc.de) joined #osdev
09:17:15 <xenos1984> moondeck: i got a similar request
09:17:35 <xenos1984> https://github.com/xenos1984/NOS/issues/1
09:17:38 <bslsk05> ​github.com: Cannot download the latest builds :( Also, a question? · Issue #1 · xenos1984/NOS · GitHub
09:17:51 --- quit: hunterlabs (Ping timeout: 276 seconds)
09:17:55 --- join: Love4Boobies (~L4B@unaffiliated/l4b) joined #osdev
09:19:55 <moondeck> Yeah, i saw that xenos1984
09:20:12 <moondeck> I mean,i think the guy is legit, but wtf is up with the floppy disk fetish xD
09:21:34 <xenos1984> well, apparently one can boot a floppy image on bare metal... but one can also do that with an iso image + grub, since grub can load the image, mount it as a virtual volume and even boot it
09:21:35 --- join: regreg (~regreg@85.121.54.224) joined #osdev
09:23:13 <moondeck> No offense, seems kinda like one of *these* guys, remember the GPU bloke?
09:23:48 <moondeck> What's even the point of using floppies nowadays?
09:24:23 <xenos1984> moondeck: he sent me spam via PM today, and probably did non even realize that i blocked him after the first line :D the GPU guy that is
09:24:27 <glauxosdever> Happy new year everyone!
09:25:11 <glauxosdever> Hm..
09:25:16 <xenos1984> for me personally, floppy images can at most be a nice and simple testbed for file system access, but that's it
09:25:27 <xenos1984> happy new year glauxosdever!
09:25:35 <glauxosdever> Floppies are old, obsolete, slow and unreliable media. I wonder who needs them still.
09:25:51 <Love4Boobies> People stuck using old systems, presumably.
09:26:09 <glauxosdever> How old? You need to draw the line somewhere.
09:26:44 <glauxosdever> I'd assume supporting systems newer than from 2000 is ok.
09:26:47 <Love4Boobies> It's not as uncommon as you think. Many military institutions are stuck using even older technologies because switching over is too expensive. FOR THE MILITARY.
09:27:05 <Love4Boobies> People still use systems from the 60s and 70s all over the place.
09:28:14 <glauxosdever> Our systems however won't be used by the military because 1) They probably don't trust us; 2) They have much higher memory/speed requirements than these systems can provide.
09:28:23 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-usoysktwjyvouowq) joined #osdev
09:28:54 <glauxosdever> (To elaborate, our OSes have much higher requirements than their systems can provide)
09:28:56 <Love4Boobies> Well, if they'd switch to a newer systems, even if it were one of ours, they'd get rid of floppies in the process for sure.
09:29:01 <Love4Boobies> It's not the hardware that is expensive.
09:29:06 <Love4Boobies> It's rewriting the software stack.
09:30:38 --- quit: jsgrant_ (Remote host closed the connection)
09:30:39 <Love4Boobies> It's also why until very recently there was more COBOL code written than code in any other language.
09:30:51 <Love4Boobies> I don't think it's the case any longer but it was until a couple of years ago.
09:31:34 <Love4Boobies> I'm not talking about how widely deployed the code was, of course. That couldn't have been the case.
09:31:52 <Love4Boobies> Just sheer amount of lines.
09:32:28 --- quit: Belxjander (Ping timeout: 240 seconds)
09:32:48 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
09:33:06 <glauxosdever> I hope I'll never come across such obsolete code.
09:33:11 --- quit: hunterlabs (Ping timeout: 265 seconds)
09:34:35 --- join: jsgrant_ (~jsgrant@71-11-142-172.dhcp.stls.mo.charter.com) joined #osdev
09:34:53 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-vwqbhnoznajkmyrj) joined #osdev
09:37:14 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
09:38:07 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
09:43:48 --- quit: caen23 (Ping timeout: 260 seconds)
09:49:55 <geist> also COBOL is very wordy :)
09:50:09 <geist> but yeah i think there's still a lot of it running banks and other institutions like that
09:50:24 <geist> honestly if it has better wrapping rules I'd prefer something like that to pure C/C++
09:50:55 --- quit: Pessimist (Remote host closed the connection)
09:51:11 <moondeck> LUA is nice
09:51:57 <geist> it's okay. certainly useful in a lot of places
09:52:17 <geist> it's definitely the first choice i'd have for needing to embed some scripting thing in a larger project
09:52:20 <moondeck> Dont confuse it with lua
09:52:31 <geist> ah then i guess i dont know what you're talkong about
09:52:45 <moondeck> https://github.com/mniip/LUA
09:52:46 <bslsk05> ​mniip/LUA - A programming language based upon the lua programming language (0 forks/27 watchers)
09:52:54 <geist> uh. okay then
09:52:59 <moondeck> i love the syntax
09:54:58 --- quit: osa1 (Ping timeout: 240 seconds)
09:57:07 --- join: Redfoxmoon (~red@77.16.76.85.tmi.telenormobil.no) joined #osdev
09:57:42 <moondeck> https://github.com/glauxosdever/glaux-os-third/issues/1
09:57:43 --- join: MarcinWieczorek (~MarcinWie@89-77-70-23.dynamic.chello.pl) joined #osdev
09:57:44 <bslsk05> ​github.com: Could Glaux OS fit on a floppy? · Issue #1 · glauxosdever/glaux-os-third · GitHub
09:57:54 <moondeck> glauxosdever you might wanna see this
09:58:24 <Stary> lol
09:58:32 <moondeck> Stary yeah
09:58:37 <Stary> also lmao, LUA
09:58:43 <moondeck> the guy opened like 30 issues, all about the same thing
09:58:47 --- quit: Redfoxmoon (Changing host)
09:58:47 --- join: Redfoxmoon (~red@unaffiliated/kitt3n) joined #osdev
09:59:34 --- quit: hunterlabs (Ping timeout: 240 seconds)
10:03:43 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-ocibenwjkkosavnd) joined #osdev
10:04:27 --- quit: shymega (Quit: Peace out.)
10:06:51 <glauxosdever> I don't know if I should be honest...
10:07:43 --- join: shymega (~shymega@torbaytechjam/shymega) joined #osdev
10:07:47 <moondeck> I would just facepalm glauxosdever
10:07:50 <bcos> Don't be honest, be mean. Say that you don't want the excellent reputation of your OS to be worsened by the risk of bugs from coreboot
10:07:52 <bcos> :-)
10:07:55 <Levex> Hello #osdev!
10:07:59 <Levex> Happy New Year!
10:08:04 <moondeck> bcos is it so buggy though
10:08:10 <geist> wait, so someone is going through and filing the floppy bug on everyone's project?
10:08:11 <moondeck> Hacky Noob Year Levex!
10:08:14 --- quit: shymega (Client Quit)
10:08:14 <moondeck> geist indeed
10:08:25 <geist> man, i feel pretty left out. no bugs on mine
10:09:02 <glauxosdever> bcos: I don't have an excellent (or even good) reputation now. Hopefully in 5 years I will have one.
10:09:04 --- quit: heat (Remote host closed the connection)
10:09:25 <moondeck> bcos what is reputation?
10:12:18 --- quit: svk (Quit: Leaving)
10:13:44 <bcos> moondeck: It's relatively easy to write code that works under ideal conditions; but writing code that works under unusual conditions (including things like "over-temperature at power-on" and various forms of hardware failures and incompatibilities) is multiple orders of magnitude harder. I'd wouldn't trust coreboot for the latter
10:15:04 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
10:15:46 <moondeck> Right
10:16:00 <mniip> moondeck, I think right
10:16:10 <mniip> moondeck, I know right*
10:16:42 <variable> absolutely wrong
10:17:26 --- part: ebrasca left #osdev
10:17:26 <bcos> (but mostly; I hate spammers - if a spammer is trying to promote something then I'll try to "unpromote".. ;-)
10:17:52 <moondeck> But i guess their point is "Would you trust government loomynarty backdoors!?!?!?!?! U DONT RESPECC UR PRIVACY"
10:17:55 <variable> I love spammers. they ensure my friends have job security
10:18:02 --- join: sandeepkr (~sandeepkr@ec2-52-29-251-54.eu-central-1.compute.amazonaws.com) joined #osdev
10:18:13 * variable notes his trolling efforts today are going unnoticed
10:21:47 <Levex> people are just too busy to care about trolling efforts these days... :-)
10:23:14 --- quit: hunterlabs (Ping timeout: 240 seconds)
10:25:27 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-itlxxuxtrtxoziad) joined #osdev
10:26:25 <glauxosdever> Answered..
10:28:37 <Love4Boobies> geist, do you like Lua because they've made it easy to incorporate it into projects? Or were you talking about the language?
10:30:29 <Love4Boobies> bcos, then I promote not eating poop.
10:30:38 <variable> hai Love4Boobies
10:30:42 <Love4Boobies> hi
10:31:41 <geist> yes
10:31:42 <graphitemaster> Lua is a mess to be honest
10:31:54 <graphitemaster> It's small and nicely embeddable and easy to use, yes.
10:31:55 --- part: Love4Boobies left #osdev
10:31:56 <variable> are we having a language war?
10:32:04 <variable> cause TOD is the only correct language
10:32:04 <graphitemaster> But there's lots of decisions they made that are kind of cluky.
10:32:04 <geist> variable: looking for a fight?
10:32:08 --- join: Love4Boobies (~L4B@unaffiliated/l4b) joined #osdev
10:32:14 <Levex> Haskell...
10:32:16 <glauxosdever> https://github.com/informer2016/Not_a_bot_-_I-m_a_person_looking_for_the_best_floppy_OS <- lol?
10:32:16 <bslsk05> ​informer2016/Not_a_bot_-_I-m_a_person_looking_for_the_best_floppy_OS - I am not a bot, just a person looking for the best floppy OS (0 forks/0 watchers)
10:32:19 <geist> graphitemaster: yeah as a language i'm not blown away, but it's nice to embed into things
10:32:23 <Levex> ;-D
10:32:34 <geist> has fairly decent binding support for other languages and is fairly lightweight
10:32:36 <Love4Boobies> Ugh. Stupid debian trackpad support. Wanted to select a window and it closed it.
10:32:41 <variable> glauxosdever: 404
10:32:44 <variable> Love4Boobies: lol
10:32:45 <graphitemaster> Also Lua's source code is pretty ugly as well, really difficult to modify it, very idiomatic C, very dense, etc, etc.
10:32:57 <variable> TOD is much better than lua, for everything
10:32:59 <geist> indeed. that's probably one of the reasons its so embeddable
10:33:06 <geist> relies on fairly dumb C
10:33:21 <glauxosdever> variable: It's just empty.
10:33:24 <variable> glauxosdever: o
10:33:30 <geist> hard to read, etc, but it doesn't need higher level runtimes
10:33:43 <variable> glauxosdever: what's the context of the joke?
10:33:52 <geist> iirc, it depends on very little libc. i think it only uses realloc
10:34:00 <glauxosdever> It's just that person that has been commenting on various OS projects, requesting to add floppy support.
10:34:11 <variable> glauxosdever: lol
10:34:19 <geist> i remember that because it actually uses realloc(null) and other strange uses of it
10:34:28 <variable> I proposed removing floppy drive support recently
10:34:37 <graphitemaster> There's some runtime characteristics of Lua that kind of suck tho, not having real arrays hurts performance a lot, using tables with strict integer keys does optimize to arrays generally speaking in stuff like LuaJIT but eh. The GC is non-deterministic, it's really difficult to debug Lua code due to it's dynamic nature (it really needs optional typing)
10:34:47 <graphitemaster> you can't do any real big software projects in Lua, it would be painful.
10:34:53 <geist> right
10:35:03 --- quit: hunterlabs (Ping timeout: 265 seconds)
10:35:28 <geist> hence why it's good for little scripting stuff to embed into larger projects
10:35:42 <geist> even embedded in the strictest sense (small single purpose machines)
10:35:45 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-fzkwajtucvqoyccb) joined #osdev
10:37:06 <graphitemaster> I find that the best way to use Lua in "big" projects that embed it is to start with a simple integer pool allocator (like fds) and then you have "objects" in your code that can be allocated just like kernel objects actually but backed by a simple integer you can hand down to Lua and it can work with, the whole meta table stuff to define objects seems like a waste of time to me, considering you're adding some indirection for __index
10:37:06 <graphitemaster> and what not metamethods
10:37:21 <Griwes> http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table fun fun fun
10:37:22 <graphitemaster> this is what we do at work, it also lifts all allocaiton work out of Lua which is a win.
10:37:32 * geist nods
10:38:32 <graphitemaster> I like to do "bottom bits" describe the object type, "top bits" describe the object index, and I can just type verify and index verify at the entry point
10:38:44 <graphitemaster> and then the index is literally an index into a flat array
10:39:00 <graphitemaster> it's simple, unimpressive and just works really
10:39:22 --- quit: grzesiek (Remote host closed the connection)
10:40:05 <geist> yah
10:40:38 <geist> i like the fact that by and large lua as a project has not been climbing the complexity ladder like so many others
10:40:43 <variable> Griwes: reading that it seems like some kind of hardware level mmu info leakage to userspace?
10:40:44 <geist> it's just about as dumb as it was 10 years ago or so
10:40:45 <variable> if so, meh
10:40:58 <glauxosdever> https://github.com/omarrx024/xos/issues/21 <- Seems that Informer2016 guy has been requesting floppy support since September..
10:40:59 <bslsk05> ​github.com: xOS floppy image - is it possible? · Issue #21 · omarrx024/xos · GitHub
10:41:00 <geist> so folks have figured out how to use it well
10:41:12 <graphitemaster> I've seen really complicated object allocation mechanisms for C/C++ <=> Lua bridging, with custom metatables, __index metamethod hacks, and yeah it's super cool and impressive, sure but I think it's just out of character for Lua personally and it's actually confusing to debug.
10:41:30 <graphitemaster> Just have some wrapper objects defined in Lua that wrap an integer, that's so much cleaner idk.
10:41:52 <Love4Boobies> geist, it's hard to say whether it's better to know how to use a bad tool well or to not know how to use a good tool well yet.
10:42:04 <Love4Boobies> I'm tempted to go with the latter.
10:42:17 <geist> my constraints are in general that in certain places, there are no good tools
10:42:33 <geist> specifically, i'm thinking about scripting in an embedded environment, where you dont have a huge pile of memory
10:42:55 <geist> lua iirc has support for read-only objects as well, which is a massive win, since you can map the bytecode in flash and not have to fiddle with it
10:43:03 <graphitemaster> Yeah our Lua is super tight, I have a custom Lua heap (implemented ontop of a buddy allocator) and our most complex stuff is still using < 16K of memory
10:43:21 <Griwes> variable, I think the author might be right that it might be a hypervisor privilege escalation
10:43:25 <geist> exactly. i've heard of squirrel in a similar area, but aside from that there just aren't a lot of really good solutions
10:43:48 <variable> Griwes: still in middle of reading to the end
10:44:56 --- quit: listenmore (Quit: Konversation terminated!)
10:45:00 <graphitemaster> It's impressive to see how tight Lua's runtime can be in memory when you consider just how dynamic the language is.
10:45:08 <graphitemaster> Dynamic languages tend to require a lot of memory.
10:45:30 <graphitemaster> Look at Python for christ sake. That thing take like 4GB to run a simple HTTP server.
10:46:15 <graphitemaster> You can use LuaSocket library in Lua and do the same HTTP server in like 1K of RSS.
10:46:20 <geist> word
10:46:38 <graphitemaster> well, I don't think you could run an HTTP server in a single word of memory
10:46:42 <graphitemaster> that could be a fun challenge tho
10:47:11 <clever> also, lua's engine isnt that dependant on a posix system
10:47:35 <clever> you can easily just remove the stdio stuff from it, and compile it to run in ring0
10:48:15 <variable> Griwes: oh, I was commenting in the KAISER stuff
10:48:19 <variable> which is pretty uninteresting
10:48:21 <clever> once i get the boot and memory allocation tackled, i could probably make an OS that runs lua as the "userland" lol
10:48:43 <geist> yep
10:48:53 <graphitemaster> Lua in ring0 is not a bad idea if you explicitly disable execution of Lua bytecode
10:49:08 <graphitemaster> the bytecode can be hand crafted to arbitrary code execution easily
10:49:10 <geist> clever: that's precisely what i'm thinking about with embedded OS stuff. basically you bring up a little rtos, then put lua on it and run your 'application' in lua
10:50:05 <graphitemaster> that or Javascript :P
10:50:14 <graphitemaster> nearly all applications are Javascript now anyways
10:50:19 <geist> http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table is interesting
10:50:25 <graphitemaster> Just put the JSVM in the kernel...
10:51:06 <variable> graphitemaster: that's too much: what about WebASM
10:51:43 <variable> Griwes: okay, finally got the end after daydreaming a bit
10:51:56 <variable> the conclusion seems reasonable
10:52:19 <variable> now, if only it wasn't a fscking tumblr blog so I could follow it
10:54:35 --- quit: epony (Quit: QUIT)
10:54:43 --- quit: impertinente (Ping timeout: 264 seconds)
10:56:08 <geist> looks scary. i'm guessing he's right and there's a hw bug that they're trying to work around
10:56:20 --- quit: moondeck (Ping timeout: 240 seconds)
10:56:20 <dhoelzer> What's wrong with tumblr blogs?
10:57:58 <graphitemaster> geist, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a89f040fa34ec9cd682aed98b8f04e3c47d998bd
10:57:59 <bslsk05> ​git.kernel.org: kernel/git/torvalds/linux.git - Linux kernel source tree
10:58:17 <variable> dhoelzer: RSS is broken
10:58:22 <dhoelzer> ah
10:58:51 <geist> graphitemaster: wow, yeah
10:59:16 <variable> that was linked from the article
10:59:31 --- join: clickjack (~clickjack@90.95.19.47) joined #osdev
11:00:12 <clever> geist: there is also a minecraft mod called opencomputers, that uses a java implementation of lua, which has the added benefit that it can serialize the entire state of the lua engine, so it can just suspend the VM at any time and save it to disk
11:00:13 <geist> so if i read that right, the solution is to unmap the kernel while user space is running
11:00:34 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
11:00:36 <dhoelzer> that's what I read geist
11:01:04 <graphitemaster> geist, tl;dr page table walks conducted by the MMU in all x86 CPUs during virtual to physical address translation leave a trace in the last level cache, simple side channel attack on the MMU operations left you leak both data and code pointers, thus breaking ASLR
11:01:19 <graphitemaster> s/left/let/
11:01:53 <geist> makes sense. surprised it doesn't stop walking after it hits the first level page table entry though, if it has the supervisor bit set on level 1
11:02:45 <geist> and thus would only really leak the presence of the top level page table, which user space could infer as well
11:02:47 <variable> graphitemaster: I generally assume ASLR is broken
11:03:00 <graphitemaster> it's particularly _bad_ because some security team already _wrote_ Javascript for the webbrowser that permits ring0 access on both Linux and Windows
11:03:19 <graphitemaster> which is very impressive
11:03:22 <variable> its a vaguely useful tool for increasing the workload for an exploit by a constant factor
11:03:28 <graphitemaster> you load this webpage, congrats the kernel is now hosed.
11:03:34 <variable> graphitemaster: isn't that rowhammer revisited?
11:03:38 <graphitemaster> yep
11:04:09 --- join: bm371613 (~bartek@89-64-31-161.dynamic.chello.pl) joined #osdev
11:04:29 <graphitemaster> basic attack is rowhammer + side channel on mmu + find kernel data + poke it with the right bits with rowhammer + ring0 access
11:04:38 <graphitemaster> all with plain javascript
11:05:34 <graphitemaster> the solution that the kernel choose was to throw away all of it's page tables on userspace, inbetween system calls
11:06:00 <graphitemaster> it also disables vdso
11:06:06 <geist> oh, maybe the point is less that the cpu has to go fetch it for mmu ops, and more that it's forcing the cpu to dump the TLB when switching to the kernel for a page fault
11:06:12 <geist> because it's the page fault code path that's leaving the trail
11:06:25 <graphitemaster> geist, correct
11:06:42 <geist> so seems like another mitigation would be to just manually dump the TLB entirely on a page fault
11:06:52 <geist> instead of having to unmap the kernel entirely
11:07:07 <geist> but i guess the kernel is probably reentrant on most of the page fault path, so that wouldn't necessarily help
11:08:04 <geist> it would implly that using PCID or even arm cpus with separate asids for the kernel would still be technically suceptable to somethingl ike this, maybe
11:08:13 <graphitemaster> the other solution would be to just shuffle the access bits around in the page table entries because that would light up the mmu when an access is made on it, thus effectively making a side channel attack impossible
11:08:33 <graphitemaster> tho that seems more difficult
11:09:15 <geist> the wording of that change implies that it's an inheirent design issue with x86, and not one specific core or whatnot
11:09:25 <graphitemaster> because it is
11:09:46 <graphitemaster> the trailing data it keeps around is referenced in the exception
11:09:59 <graphitemaster> at least for Intel :P
11:10:21 <geist> dont see why AMD would work any differently
11:10:56 <graphitemaster> for Intel, it appears it puts the faulting addresses into cache to be picked up by smm and then copied into a register for the exception it triggers so kernel can do something with it
11:11:11 <graphitemaster> which is just an awful design decision
11:11:19 <graphitemaster> the AMD CVE is worded differently.
11:11:21 <geist> you're not just talking about cr2?
11:11:39 <doug16k> graphitemaster, what's the code to get _values_ from the tlb by side channel?
11:12:25 <graphitemaster> geist, yes
11:12:34 <doug16k> and not just vague nearly useless "maybe something mapped there" clues
11:12:45 <graphitemaster> mmu puts faluting address in top of cache, smm copies it into cr2
11:13:00 <geist> eh? i'm not so sure about that
11:13:10 <geist> that would imply that there'sa *always* code running in smm that does that
11:13:20 <geist> i can see perhaps there being an option so that smm can intercept
11:13:35 <graphitemaster> geist, when an exception is triggered smm is entered
11:13:47 <geist> yes but what code where is running in smm? is it in rom?
11:14:00 --- join: epony (~nym@77-85-135-215.ip.btc-net.bg) joined #osdev
11:15:16 --- quit: epony (Max SendQ exceeded)
11:15:34 <geist> could be microcode that you're talkinga bout though
11:16:02 --- join: epony (~nym@77-85-135-215.ip.btc-net.bg) joined #osdev
11:17:08 <doug16k> "puts the faulting address into the cache" what, there is some way of reading values in the cache that aren't memory accesses?
11:17:19 <geist> yeah i dunno what he means there
11:19:48 <graphitemaster> the way the CVE is worded and the explination at C32C was that the MMU triggers a fault and puts the faulting address in the last level of cache at the top, SMM is entered on fault then reads from the faulting address that was stored in cache via a memref (the MMU avoids PTEs when SMIACT# pin is held)
11:20:20 <graphitemaster> SMM has a "view" of CPU caches (except the top level) when SIMACT# is held
11:20:21 <geist> hmm, guess it could
11:20:55 <graphitemaster> apparently there is no way to get MMU to store in CR2
11:20:56 <geist> i'm just surprised that SMM is involved anyway, at the minimum it'd be slower to do a complete cpu context switch to another piece of code to deal with every page fault
11:20:59 <graphitemaster> due to x86's design
11:21:22 <geist> in some sense that makes sense if you replace SMM with microcode, or some sort of thing like that
11:21:42 <geist> but then maybe if they have an extremely fast mechanism to dispatch SMM then the lines are blurred
11:22:13 <geist> and that sort of makes sense, because CR2 is just some internal cpu register and if you consider the mmu to be a separate block that has no internal knowledge of the cpu
11:22:49 <geist> then a page fault would be switch to some smm code that gets something like 'mmu unit N has tripped a fault and the address and reason code is available in cache line X'
11:23:04 <geist> and then there's some sort of back door to reach into the cache line and pull the infos out
11:23:14 <graphitemaster> right
11:23:29 <geist> kind of makes sense if you consider the mmu block to be a unit that sits between the cache and memory, it can only really put bits in the cache
11:23:39 <graphitemaster> or memory
11:23:46 <geist> or memory
11:23:48 --- join: shymega (~shymega@torbaytechjam/shymega) joined #osdev
11:23:52 <graphitemaster> which is hard to do when the kernel wants to own all the memory
11:23:57 <graphitemaster> you'd have to hide memory from the kernel for that
11:23:59 <geist> actually the write path is interesting, bercause it can't trash the cache line
11:24:27 <graphitemaster> probably an xor on SIMACT# for the write or something in hardware
11:24:31 <graphitemaster> thus avoiding a trash
11:24:37 --- quit: variable (Quit: /dev/null is full)
11:24:42 * geist nods
11:25:09 <geist> could be it's not the cache but a TLB line that is getting trashed
11:25:27 <geist> perhaps it allocates a TLB line, and instead of filling it with actual data it sets an error bit and then puts the relevant info in it
11:25:35 <geist> and then the SMM code has ability to read a TLB line directly
11:26:13 <geist> well, TLB entry
11:26:14 --- join: raphaelsc (~utroz@189.26.194.247.dynamic.adsl.gvt.net.br) joined #osdev
11:26:17 --- join: m_t (~m_t@p5DDA3201.dip0.t-ipconnect.de) joined #osdev
11:27:10 <geist> well, anyway, enouhg thinking for today
11:29:16 <graphitemaster> now, what AMD does is apparently different
11:29:29 <graphitemaster> but suffers from the same problem, just in a different way
11:32:15 <geist> is there a particular CVE you're looking at?
11:32:33 --- join: moondeck (~moondeck@x1-6-a0-63-91-fb-95-b2.cpe.webspeed.dk) joined #osdev
11:32:52 <graphitemaster> CVE-2017-5925 and CVE-2017-5926
11:33:02 <graphitemaster> and also http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf
11:33:13 <graphitemaster> tho that last link says I'm wrong and the talk was wrong
11:33:16 --- quit: floatleft (Ping timeout: 252 seconds)
11:33:25 <graphitemaster> it talks about PT offsets storing part of the virtual addresses
11:33:46 --- join: floatleft (~floatleft@109.186.22.204) joined #osdev
11:35:31 <graphitemaster> geist, https://www.vusec.net/projects/anc/
11:35:32 <bslsk05> ​www.vusec.net: AnC - VUSec
11:36:09 <graphitemaster> so this is apparently pretty old https://github.com/vusec/revanc
11:36:09 <bslsk05> ​vusec/revanc - Reverse Engineering Page Table Caches in Your Processor (45 forks/286 watchers)
11:36:58 --- quit: moondeck (Ping timeout: 260 seconds)
11:37:42 <graphitemaster> https://www.youtube.com/watch?v=aILISvZlBAU
11:37:43 <graphitemaster> damn
11:37:43 <bslsk05> ​'Fast version of AnC' by VUSec (00:01:14)
11:38:30 --- quit: jack_rabbit (Ping timeout: 248 seconds)
11:38:36 <graphitemaster> that is spooky
11:39:03 <graphitemaster> geist, apparently it works on arm too
11:43:31 <geist> yeah
11:49:04 <geist> i wonder how all of this would look on POWER's flat hash table
11:49:43 <geist> since there's one big ass hash table that has at most two memory accesses to lookup, it seems like it should be generally immune to it
11:50:00 <geist> except, the virtual address + asid is run through a fairly simple hashing algorithm to determine the slot in the table
11:50:19 <geist> which might have bad properties
11:50:19 --- join: jack_rabbit (~jack_rabb@209.58.129.98) joined #osdev
11:50:34 <geist> plus if it doesn't find it in the first hit iirc it hashes again and tries one more time
11:51:06 <geist> but it shouldn't have any of these page table crossing stuff
11:59:39 --- quit: hunterlabs (Ping timeout: 252 seconds)
12:01:18 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-xmijtvynompshucr) joined #osdev
12:05:39 --- join: Goplat (~goplat@reactos/developer/Goplat) joined #osdev
12:07:03 --- join: John__ (~John__@79.97.140.214) joined #osdev
12:11:15 --- quit: epony (Quit: QUIT)
12:15:53 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
12:18:55 --- quit: regreg (Ping timeout: 256 seconds)
12:19:47 --- join: MrOnlineCoder (~MrOnlineC@195.225.231.210) joined #osdev
12:20:23 <doug16k> still getting #PF error code 9 (reserved bits set, present) that makes no sense. there are no reserved bits set
12:20:54 --- quit: hunterlabs (Ping timeout: 265 seconds)
12:22:09 <geist> my guess is there are reserved bits set. what hardware are you using?
12:23:07 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-lezsyzocdsmjzfgc) joined #osdev
12:24:31 <doug16k> https://gist.github.com/doug65536/07950a58aa66a2876e8dbcb0352a5737
12:24:32 <bslsk05> ​gist.github.com: gist:07950a58aa66a2876e8dbcb0352a5737 · GitHub
12:24:38 <doug16k> see any reserved bits set?
12:25:20 <geist> what hardware are you using?
12:25:59 <doug16k> ryzen
12:26:06 <doug16k> kvm
12:26:18 <geist> yeah, i remember AMD is much pickier about that stuff
12:26:46 <froggey> iirc the global bit should only be set in the last level entry
12:26:50 <geist> check the global bit
12:26:59 <doug16k> global is in the ignored bits in other levels
12:27:02 <geist> yeah what froggey said. this is where intel and AMD disagree i believe
12:27:09 <geist> doug16k: according to the intel manual, check the AMD manual
12:27:34 --- quit: hunterlabs (Ping timeout: 240 seconds)
12:27:35 <doug16k> so recursive page tables are fucked on AMD then?
12:27:36 <geist> i spent a few hours debugging precisely this. AMD is much stricter about unused bits. it generally specs them as MBZ instead of ignored
12:27:49 <geist> beats me, solve this problem first
12:28:23 <froggey> this bit me before (in virtualbox on intel, but that was vbox being picky, not intel)
12:28:25 <doug16k> why would it work everywhere else and suddenly not work just in this case?
12:28:34 <doug16k> it's not like this faults on the 1st instruction
12:28:53 <geist> doug16k: again, look at the manual and solve the problem first, then go back and figure out what's up
12:28:57 <doug16k> but thanks, I'll check amd manual
12:30:19 <geist> looks like the G bit is ignored in all levels except the top
12:31:18 <doug16k> yes, just found it too
12:31:31 <doug16k> and it is cleared in top
12:32:08 <doug16k> I will make sure my code never sets it in top though, to be sure
12:32:29 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-luamvdtgyrjmcjtv) joined #osdev
12:32:33 * geist nods
12:33:12 <geist> yah from glancing at it i dont see anything wrong. maybe it's the NX bit
12:35:44 <geist> or i guess the global bit could be not initialized
12:36:08 <doug16k> I check cpuid and mask off global bit if not supported. I also have CR4.NXE set
12:36:27 <doug16k> and there are tons of pages with NX, so far it has worked
12:36:35 <geist> dunno then
12:36:44 <doug16k> but ya, I need to discard my assumptions :D
12:38:25 <doug16k> / G is MBZ in PML4e on AMD <-- lol, comment needs more acronyms
12:38:51 <geist> heh, to be fair MBZ is pretty well understood
12:39:45 --- quit: hunterlabs (Ping timeout: 265 seconds)
12:41:57 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-ayncxskzlbzuluwv) joined #osdev
12:46:14 --- quit: caen23 (Ping timeout: 248 seconds)
12:48:49 <geist> i guess another alternative is what you've decoded is wrong and something has gotten runtime corrupted
12:49:04 <geist> and it's just tripping the MBZ bit
12:51:51 --- join: xerpi (~xerpi@32.red-88-23-235.staticip.rima-tde.net) joined #osdev
12:52:19 --- quit: Halofreak1990 (Ping timeout: 264 seconds)
12:52:50 <xenos1984> hm... actually that reminds me that i had the same problem (global bit set on other than the last page table level causing a page fault)
12:52:52 <xenos1984> https://github.com/xenos1984/NOS/commit/cc43dfc9ed92926a618caf0caed78aa1405e9029
12:52:54 <bslsk05> ​github.com: :warning: Mark only leaf pages as global (bit is reserved when refere… · xenos1984/NOS@cc43dfc · GitHub
12:53:39 --- quit: hunterlabs (Ping timeout: 276 seconds)
12:53:55 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-hkdtkbthhxcrlxyj) joined #osdev
12:54:42 <doug16k> I think KVM is screwing it up - it happens on a rep outsb, which is emulated
12:54:46 --- quit: jack_rabbit (Ping timeout: 248 seconds)
12:55:29 <doug16k> it's amazing KVM works at all imho
12:57:46 --- join: hiei (jaganshi@gateway/shell/elitebnc/x-mramaaodfbnkpewt) joined #osdev
12:58:27 <doug16k> geist, it's not a race, I hacked it to invlpg and restart the instruction and it infinite loops
12:58:40 --- quit: hunterlabs (Ping timeout: 250 seconds)
13:00:40 <doug16k> it's only this emulated instruction that causes a problem, so it's hard not to believe it is KVM screwing up the page walk
13:00:58 --- join: Pessimist (~Pessimist@78-62-89-218.static.zebra.lt) joined #osdev
13:00:58 --- quit: Pessimist (Changing host)
13:00:58 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
13:01:20 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-wgktnqzdndurdxqx) joined #osdev
13:01:50 <doug16k> funny thing is, that instruction works a hundred times before it hits that issue
13:05:56 <doug16k> going to change it to outb each byte from al, to see if the rep emulation is doing it
13:06:02 --- quit: hunterlabs (Ping timeout: 250 seconds)
13:07:43 --- join: KidBeta (~textual@220-244-156-86.tpgi.com.au) joined #osdev
13:08:28 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
13:09:31 <doug16k> works fine without rep outsb
13:09:59 --- join: listenmore (~strike@2.27.123.231) joined #osdev
13:12:07 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-wikzqwwnauyccaya) joined #osdev
13:22:43 <geist> interesting
13:24:51 <Sjors> happy new year to y'all! \o
13:25:29 --- mode: sortie set +b *!*@*-4980-8309-07d0-2001.dyn.estpak.ee
13:25:38 <sortie> lo
13:25:39 <sortie> lol
13:26:01 <sortie> I tell the abuser he can't keep using IPv4s for ever because they will run out. So he moves to IPv6.
13:26:06 <glauxosdever> Where did you find that?
13:26:13 <sortie> Logs
13:26:18 <glauxosdever> Oh, ok
13:26:24 <Sjors> I accidentally lost my entire first of january with sleeping
13:26:46 <sortie> I like when abusive people make basic mistakes like using the same kind of nickname, the same kind of host mask, and other stuff that just gives them away.
13:27:21 <sortie> Also I just banned 2^64 IPv6 addresses lol
13:28:01 <glauxosdever> Is ^ a XOR operator? A power operator?
13:28:27 <sortie> The power of xor.
13:28:32 <sortie> Behold!
13:30:03 --- quit: hunterlabs (Ping timeout: 276 seconds)
13:30:08 <Sjors> glauxosdever: depends on the language, I guess
13:30:22 <doug16k> I doubt he meant 66 addresses
13:30:37 <Sjors> oh, there – there it is power
13:31:01 <glauxosdever> Sjors: I read that as XOR.
13:31:04 <Sjors> does anyone here have some experience with debugging host-side drivers in VirtualBox?
13:31:13 <glauxosdever> doug16k: The compiler doesn't know.
13:31:24 <Sjors> two of my drivers aren't working in it and I'm not sure yet how to get started figuring out why not
13:31:37 <_mjg> sortie: they do it on purpose
13:32:10 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-jwtcacohswjzlxag) joined #osdev
13:32:26 <doug16k> Sjors, my first guess: I'd get virtualbox building from source and put some tracing output in that device's emulation code
13:32:54 <Sjors> doug16k: I wanted to start with that, too, but then I realized most of the drivers are in proprietary code, right?
13:32:57 <Sjors> or is that just the USB stack?
13:33:00 <_mjg> sortie: note there is 0 effect on their ability to abuse just because you banned a range
13:33:06 --- join: macdonag (~macdonag@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
13:33:53 <doug16k> Sjors, I'd expect the devices to be emulation, how else would it work? it's not doing pass-through, right?
13:34:17 <Sjors> doug16k: nah, they are emulated, but VirtualBox comes with this blob of Oracle extensions containing drivers
13:34:28 <doug16k> ah
13:34:41 <Sjors> https://www.virtualbox.org/wiki/Downloads
13:34:43 <doug16k> what device?
13:34:44 <bslsk05> ​www.virtualbox.org: Downloads – Oracle VM VirtualBox
13:34:48 <Sjors> ah
13:34:49 <Sjors> Support for USB 2.0 and USB 3.0 devices, VirtualBox RDP, disk encryption, NVMe and PXE boot for Intel cards.
13:34:51 <Sjors> just those
13:34:52 <glauxosdever> bash: cd: write error: Success
13:34:56 <glauxosdever> Erm? ^
13:35:15 <Sjors> so it's OK, I can live without that!
13:35:36 <sortie> _mjg: Yeah. I ban lots of ranges.
13:35:58 <sortie> _mjg: Honestly it just makes me them put in a little more effort and pisses them off at best.
13:36:14 <sortie> Now they at least need to go and get a new IP
13:36:35 <sortie> _mjg: In this case I took extra pleasure because I discovered a new IP before they had used it
13:37:21 <fujisan> Hoi Sjors gelukkig nieuwjaar
13:37:23 <_mjg> i'm pretty sure they get off on it
13:37:45 <sortie> _mjg: Some abusers? Probably. This one? I actually have no idea.
13:38:18 <_mjg> i dealt with some over the years, they always do the saeme shit in the same pattern and they always comeback
13:38:23 <glauxosdever> Wow, 89 bans in #osdev. In 2015 there were more like 30 or something.
13:38:33 <doug16k> lol, I want an IRC client that plays a pump action click-click when someone takes ops, and a shotgun blast when a user is kicked
13:39:52 <sortie> glauxosdever: Just many IPs for same abuser
13:40:03 <sortie> _mjg: Unclear what approach works better.
13:40:29 <sortie> Gave asking nicely a try and the person seemed to have a better attitude towards me but changed nothing
13:40:49 <sortie> The IRC anti abuser tech is pretty crap though
13:40:51 <_mjg> well i have no solutions, just commmenting on them being easy to spot - that's part of their game
13:41:25 <sortie> _mjg: I'm worried about the trolls that blend in and create problems, never sure who they are
13:41:36 <sortie> Been a while since we had a competent troll
13:41:58 --- quit: daniele_athome (Ping timeout: 240 seconds)
13:41:59 <_mjg> half of stackoverflow reads like that
13:42:21 <Sjors> fujisan: jij ook!
13:42:26 <fujisan> bedankt ;)
13:42:38 <sortie> At least on stack overflow you can give an answer to a stupid question, or delete it if too bad
13:43:06 <sortie> The worse attack on stack overflow would be asking questions and giving bad answers from sock puppet users and accepting them
13:43:22 <Sjors> I don't think sortie has discovered that I'm actually a blended in troll, yet
13:43:26 <Sjors> perhaps because I haven't blended in so well
13:43:36 <sortie> I'm pro blending trolls
13:43:46 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
13:43:57 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
13:44:26 <sortie> If I had some time I would love to think about proper anti spam for freenode
13:44:46 --- quit: Barrett (Read error: Connection reset by peer)
13:44:47 <sortie> I don't buy inviting an anti-spam bot to your channel is a good solution
13:47:21 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
13:47:32 <roxfan> +r on channel would help
13:47:54 <sortie> Right
13:48:11 <sortie> The good old tradeoff between registered users and anyone being able to be here
13:48:22 <sortie> I kinda want this place to remain as accessible
13:48:35 <Barrett> +r may be annoying
13:48:44 <Levex> I really don't like +r
13:49:14 <sortie> But people ought to register here
13:49:18 <Levex> one of the most beautiful things about IRC is zero registration is required for quick questions
13:50:08 <sortie> I don't so much kind if unregistered users that haven't been active are on a tighter lease if they can do most things
13:50:25 <sortie> But I don't like if they can't even say stuff or joining without registering
13:51:22 --- quit: hunterlabs (Ping timeout: 255 seconds)
13:51:53 <sortie> _mjg: Yeah it's part of their game. I normally don't ban such identifiable behavior if it's easy to change, so they don't do it, and it's easy to deal with. I like to ban more subtle stuff they can't figure out what is.
13:52:12 <sortie> What annoys me is that freenode fails to handle abusers that cross between communities
13:52:49 <sortie> "Hey, staff, why don't you ban this person from the network that has violated rules in 7 communities? Most of us failed to ban the person."
13:53:05 <sortie> At least asking for that once didn't work out.
13:53:42 <Barrett> this is not an approach that can work really.
13:53:51 <Barrett> at least not worth it
13:54:07 <sortie> Clarify? Uncertain what you mean
13:54:48 <Barrett> you can't have the perfect society and the limit between an abuser and a clown is so little
13:55:00 <Barrett> there's no general meter for solving that
13:55:26 <glauxosdever> If communities fail to ban a user, then how will the network not fail?
13:55:40 <sortie> glauxosdever: The network has more information and more skill.
13:56:14 <glauxosdever> Apart from an IP and/or a hostmask, what more can it have?
13:56:16 <sortie> They know their technology and can help set up proper bans that better catch the right person
13:56:32 <Barrett> you will never kill an intentionated troll
13:56:50 <Barrett> if he have minimal ridicolous skills
13:57:20 <Barrett> *motivated
13:57:33 <geist> Ridiculous SKillz
13:57:39 <geist> BE WARNED
13:57:43 <sortie> The network can unify reports
13:57:44 --- join: immibis (~chatzilla@122-59-200-50.jetstream.xtra.co.nz) joined #osdev
13:58:06 <sortie> "Oh the troll is back in #foo? OK we banned that IP from the network, so now #bar, #qux, etc. won't be affected"
13:58:24 <geist> iirc the current one is coming in from different ips, like it's a botnet thing
13:58:35 <sortie> "OK, we have a pattern that identifies the troll, but may catch a few too many people. We can selectively apply that pattern to #foo and #bar."
13:58:37 <Barrett> yeah, that's the point
13:58:40 <geist> because of the aforementioned Ridiculous Skills
13:58:52 <Barrett> and he have surely more ips than how much the network can ban
13:59:01 --- join: __ACPI__ (5e4226f9@gateway/web/freenode/ip.94.66.38.249) joined #osdev
13:59:08 <geist> +5 Ridiculous Skillz
13:59:27 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-czfundfkqsoiuabo) joined #osdev
13:59:39 <sortie> "OK this IP range is public proxies. We can pool those ranges together and either ban some of them from the network entirely, or we can let channels decide they don't want these suspicious ranges."
13:59:39 <Barrett> sortie, on the long run this solution can lead to lots of innocent users banned
13:59:56 <Barrett> and trust me, no one want to do something like that daily
14:00:23 <sortie> Barrett: That already happens. I bet a lot of channels would have straight up just banned Estonia.
14:00:31 <sortie> Or a given ISP
14:00:38 <Barrett> we don't want that to happen more...
14:00:41 <geist> yah my ipv6 range at linode used to get taken out fairly often
14:00:53 <geist> i think it switched back to using ipv4 because it was annoying enough
14:00:54 <sortie> Barrett: With my proposed approach, the filters set up can be applied selectively to channels that are OK with this.
14:01:05 --- quit: bm371613 (Quit: Konversation terminated!)
14:01:27 <sortie> Barrett: Additionally, people should register. It helps protect your identities. Identified users can be exempt from these bans.
14:01:29 <glauxosdever> sortie: All of home.otenet.gr is banned in some channel I tried to join (for the first time!) somewhen.
14:01:57 <sortie> In any case, these are real problems, and freenode expects each channel to solve them poorly
14:02:09 <sortie> With more coordination and handling at the network level, abuse can be better handled.
14:02:37 <xenos1984> sortie: i hope you won't ban all of estonia :D
14:02:43 <Barrett> sortie, too strict policies may lead to bad things to happen
14:03:07 <Barrett> I will make an example, suppose user X hates me in his channel and decides I'm a troll, while I'm not
14:03:07 <Sjors> iirc freenode at one point banned every user that sent some string over a channel
14:03:13 <sortie> xenos1984: I'm not doing that ocf course
14:03:22 <Sjors> because the string was picked up by intrusion detection systems and caused them to close the connection
14:03:27 <Barrett> I may risk to be banned from other chatrooms because we have a troll-op
14:03:28 <sortie> Barrett: Too loose policies will lead to bad things as well
14:03:34 <Sjors> so just saying that string would kick a lot of users off the network, but at least the sender would be k-lined as well
14:03:42 <Barrett> yeah, but freenode is realatively clean :)
14:03:44 <xenos1984> sortie: i know :)
14:03:47 <Sjors> so the freenode ircd (was it hyperion?) did that at some point
14:03:50 <glauxosdever> Can't remember the channel anyway, but I was like "Wat?".
14:03:53 <sortie> Barrett: Obviously any competent anti-abuse system needs to be resilient against the abusers just reporting normal users
14:04:06 <sortie> Well, not obviously, because somehow lots of sites fail at such a basic properly
14:04:06 <Levex> ... in a perfect world
14:04:28 <Barrett> yeah.
14:04:33 <sortie> It's why you get experienced anti-abuse people invoked, pay them, and let them help you set up something to the best of our collective abilities
14:04:51 <__ACPI__> I'm abuse! I abuse OS developers!
14:05:02 <sortie> __ACPI__: I am Windows.
14:05:16 <__ACPI__> Erm..
14:05:38 <__ACPI__> Here is whatever you need. I don't need to abuse you.
14:05:43 <sortie> :D
14:06:34 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
14:07:20 --- quit: sortie (Quit: Leaving)
14:07:41 <__ACPI__> Smells like non-Windows afterall..
14:07:44 --- quit: freakazoid0223 (Ping timeout: 256 seconds)
14:08:12 --- quit: __ACPI__ ()
14:09:00 --- quit: hunterlabs (Ping timeout: 255 seconds)
14:09:07 --- join: mhi^ (~mhi^@unaffiliated/mhi/x-9993184) joined #osdev
14:09:33 <glauxosdever> Do you still remember the ELTORITO joke?
14:10:31 --- quit: mhi^_ (Read error: Connection reset by peer)
14:10:31 --- quit: Dotti_ (Ping timeout: 264 seconds)
14:10:37 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
14:10:38 --- join: Dotti (~dotti@255.ip-37-59-117.eu) joined #osdev
14:11:08 <sortie> IP bans should also expire
14:11:14 <Levex> ELTORITO!
14:11:29 <sortie> Probably expire at the scale of a year. Maybe earlier if whois changes.
14:11:45 <sortie> Renew them as long as the IP attempts to connect, until a maximum ban period
14:12:11 <sortie> Right now I just ban people in here and those are kinda "forever" until they get lost and I don't have paperwork on why I banned that IP
14:12:16 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
14:13:19 --- quit: freakazoid0223_ (Ping timeout: 252 seconds)
14:13:28 <glauxosdever> sortie: Then maybe start keeping paperwork about that? :p
14:13:44 <sortie> Yes
14:13:56 <sortie> Or you could do it for me
14:14:04 <sortie> All the bans happen in public you know
14:14:20 <sortie> Annoying thing about trolls is that it happens on their schedule, you know?
14:14:40 <sortie> Could trolls *please* announce they will be around Monday from 8 to 10 if that's convenient for me
14:14:51 <glauxosdever> Unfortunately I don't have too much spare time either.
14:17:46 <mischief> just make a bot
14:17:49 <mischief> .theo
14:17:50 <glenda> You can figure out what I'm not saying on this line.
14:18:01 <glauxosdever> .bullshit
14:18:01 <glenda> API template
14:18:03 <glauxosdever> .bullshit
14:18:03 <glenda> overflow-preventing flexible hardware general-purpose persistence engine out-scaling generator
14:18:07 <glauxosdever> ^ NICE
14:18:28 <glauxosdever> .ken
14:18:28 <glenda> who cares.
14:18:59 <glauxosdever> Anyway, goodnight!
14:19:02 --- quit: glauxosdever (Quit: leaving)
14:21:43 --- join: Asu` (~sdelang@92.184.96.42) joined #osdev
14:24:03 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-gcjxkbhotbdeumws) joined #osdev
14:24:37 --- quit: xenos1984 (Quit: Leaving.)
14:25:11 --- quit: Asu (Ping timeout: 268 seconds)
14:25:52 --- quit: macdonag (Quit: macdonag)
14:27:14 --- join: Asu (~sdelang@92.184.96.26) joined #osdev
14:27:53 --- quit: Asu` (Ping timeout: 260 seconds)
14:28:52 --- quit: hunterlabs (Ping timeout: 272 seconds)
14:31:10 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-boshvoeamwkhvsts) joined #osdev
14:33:42 --- join: GautamS (~GautamS@59.182.251.31) joined #osdev
14:40:14 --- quit: hunterlabs (Ping timeout: 240 seconds)
14:41:16 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-rkwnydpuavbfvtsa) joined #osdev
14:41:31 --- quit: quc (Ping timeout: 264 seconds)
14:44:34 --- join: GautamS_ (~GautamS@59.182.252.22) joined #osdev
14:45:13 --- join: dbittman (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
14:45:56 --- quit: m_t (Quit: Leaving)
14:47:23 --- quit: GautamS (Ping timeout: 268 seconds)
14:47:23 <GautamS_> What's some of the nicer literature on the x86 platform? I've always been told to refer to Intel's manuals and I realise I might have to do that eventually, but learning the basics of system development from the manual is like learning English from a dictionary.
14:47:56 <sortie> GautamS_: See the books in the channel topic
14:48:00 <Barrett> GautamS_, most people start from osdev.org tutorials
14:48:15 <GautamS_> sortie, Crap missed that
14:50:21 <dbittman> happy new year everyone! :)
14:53:20 --- quit: GautamS_ (Ping timeout: 240 seconds)
14:53:26 --- quit: Asu (Remote host closed the connection)
14:53:53 --- join: Asu (~sdelang@92.184.96.26) joined #osdev
14:57:58 <Levex> dbittman: happy new year!
15:05:56 --- quit: KidBeta (Changing host)
15:05:56 --- join: KidBeta (~textual@hpavc/kidbeta) joined #osdev
15:07:10 <geist> doug16k: did you figure out the page table thing yet?
15:08:03 --- quit: mquin (Remote host closed the connection)
15:08:05 --- quit: hunterlabs (Quit: EliteBNC 1.6.5 - http://elitebnc.org)
15:08:16 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-szxvzuqrfbqyfikj) joined #osdev
15:08:18 --- quit: Asu (Quit: Konversation terminated!)
15:09:14 --- join: mquin (~mquin@freenode/staff/mquin) joined #osdev
15:10:59 --- join: m712 (~annoying@unaffiliated/thefam) joined #osdev
15:13:21 --- quit: hunterlabs (Ping timeout: 255 seconds)
15:13:50 --- quit: xerpi (Quit: Leaving)
15:22:01 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-uixwxwrtdovrckyq) joined #osdev
15:23:33 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
15:27:35 --- quit: MrOnlineCoder (Read error: Connection reset by peer)
15:37:20 --- quit: Pessimist (Ping timeout: 240 seconds)
16:06:08 --- quit: hunterlabs (Ping timeout: 265 seconds)
16:06:59 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-tsbnpruyccjomaig) joined #osdev
16:16:55 --- quit: Shamar (Quit: leaving)
16:17:25 <doug16k> geist, kvm is throwing an inappropriate page fault in the rep outsb emulation
16:18:10 --- quit: hunterlabs (Ping timeout: 252 seconds)
16:18:54 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-xipaswkljjzamtkp) joined #osdev
16:19:57 <doug16k> if I for-loop outb each character, the CPU has no problem with my page tables
16:21:11 <Mutabah> doug16k: DF incorrectly set?
16:21:14 <doug16k> should I flush the tlb for pte mappings every context switch or take vmexit spam for debug/serial output?
16:21:20 <doug16k> Mutabah, no, I checked
16:21:31 <Mutabah> CR2 pointing to a populated and valid page?
16:21:40 <doug16k> yes it fully works if I don't rep outsb
16:21:51 <doug16k> and it works with rep outsb in tcg
16:22:06 <doug16k> kvm is not doing the page walk correctly in rep outsb emulation
16:22:08 <Mutabah> That's not what I asked
16:22:22 <Mutabah> Have you checked CR2 in the fault handler?
16:22:26 <doug16k> yes cr2 points to perfect page
16:22:27 <doug16k> yes
16:22:56 <Mutabah> crosing a page boundary? Newly mapped page?
16:23:17 <doug16k> not crossing boundary, I already invlpg and retried, it's not a race, it's not newly mapped
16:23:26 <doug16k> it's a pre-committed stack page
16:24:38 <doug16k> don't believe it is KVM?
16:25:11 <doug16k> how could reading the memory on the cpu work and rep outsb not work
16:26:24 <doug16k> tlb right? well, if I invlpg and return from the #PF, how could it rethrow? easy, the KVM emulation code is wrong
16:32:26 --- quit: vaibhav (Quit: Leaving)
16:32:35 <_mjg> does something else reproduce the problem?
16:32:45 <_mjg> e.g. qemu without kvm or virtualbox
16:33:12 <Kazinsal> would be curious to see rhw results
16:36:24 <doug16k> it works in bochs and tcg
16:37:18 <doug16k> tcg = qemu without kvm, but I'm sure you knew that
16:38:04 --- quit: hunterlabs (Ping timeout: 272 seconds)
16:40:04 --- join: voidah (~voidah@unaffiliated/voider) joined #osdev
16:40:08 <Mutabah> VirtualBox would be interesting
16:40:22 <Mutabah> Or KVM on a different machine
16:40:38 <Mutabah> Does your machine have VMX? Is qemu using it? Or is it doing segmentation tricks?
16:40:57 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-rsfhnnqweskvxuzj) joined #osdev
16:41:15 --- quit: sortie (Quit: Leaving)
16:41:15 <doug16k> yes it is a ryzen
16:41:26 <doug16k> it runs vms blazing fast
16:41:58 <Mutabah> So, iirc that doesn't do TLB stuff in software, it's using two-level paging in the CPU
16:42:12 <Mutabah> There's no hypervisor interaction at all...
16:42:16 <doug16k> rep outsb does a vmexit and it emulates it
16:42:20 <Mutabah> Oh?
16:42:27 <Mutabah> Oh, right.
16:42:40 <Mutabah> Try a newer qemu?
16:43:03 <Mutabah> Check the bug tracker, or even check the source and raise a bug
16:43:11 <doug16k> I contribute to qemu, I run master branch
16:43:13 --- quit: Belxjander (Ping timeout: 260 seconds)
16:43:44 <Love4Boobies> Then assign the bug to yourself.
16:43:49 <Love4Boobies> That will show them!
16:43:54 * Love4Boobies shrugs.
16:44:29 <Love4Boobies> Hey, QEMU has a new Web site.
16:44:43 <doug16k> I'm digging around kvm for it but yeah, it probably is in the qemu code now that you mention it
16:44:50 <doug16k> kvm likely punts the vmexit to qemu
16:45:00 <Love4Boobies> And it's at version 2.11? I think the last time I used it it was 0.9 or something.
16:45:20 <doug16k> 2.11.50
16:45:57 <doug16k> there is more than 0.0000000000000000000000% chance of qemu accepting a fix for it too
16:46:16 <Love4Boobies> Oh, nice, there's hardware acceleration for Windows now?
16:46:17 <doug16k> I'd expect to grow wings and fly away before kvm even looks at a patch
16:46:47 <Mutabah> Yeah, looks like windows support has grown quite a bit recently
16:46:52 <Love4Boobies> Also, I believe there's at least another QEMU developer on this channel.
16:46:55 <Mutabah> I'm running a ARM VM on windows with it atm :)
16:47:45 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-oyrilnelpqtcuzql) joined #osdev
16:47:56 <Love4Boobies> Can't remember who it was.
16:49:24 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
16:53:54 --- quit: hunterlabs (Ping timeout: 272 seconds)
16:55:07 <doug16k> yeah I remember now looking at the rep outsb emulation. it breaks it down into a loop of individual outs to the device emulation code
16:55:40 --- quit: Goplat ()
16:56:13 <doug16k> but it's still half decent, it's the single vmexit. would be nice if devices could accept a block of outs though
16:59:21 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-byiamwpzdxevnpep) joined #osdev
17:01:58 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:06:00 --- quit: hunterlabs (Ping timeout: 252 seconds)
17:07:04 --- join: sinetek_ (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
17:08:14 --- join: GautamS (~GautamS@59.182.252.249) joined #osdev
17:08:36 --- quit: Nach0z (Ping timeout: 268 seconds)
17:10:27 --- join: hppavilion[1] (~dosgmowdo@rrcs-24-43-8-234.west.biz.rr.com) joined #osdev
17:10:54 --- quit: Barrett (Quit: exit)
17:11:20 --- quit: Belxjander (Ping timeout: 240 seconds)
17:12:44 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
17:13:02 --- quit: hppavilion[1] (Read error: Connection reset by peer)
17:14:27 --- join: hppavilion[1] (~dosgmowdo@rrcs-24-43-8-234.west.biz.rr.com) joined #osdev
17:20:35 --- join: Nach0z (~nach0z@c-24-126-182-195.hsd1.ga.comcast.net) joined #osdev
17:20:35 --- quit: Nach0z (Changing host)
17:20:35 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
17:22:07 --- quit: hppavilion[1] (Quit: HRII'FHALMA MNAHN'K'YARNAK NGAH NILGH'RI'BTHNKNYTH)
17:36:00 --- quit: sinetek_ (Quit: This computer has gone to sleep)
17:36:50 --- quit: MarcinWieczorek (Ping timeout: 240 seconds)
17:40:39 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-llqexlnlmjretbiv) joined #osdev
17:40:52 --- quit: GautamS (Remote host closed the connection)
17:45:49 --- quit: dustinm` (Quit: Leaving)
17:45:50 --- quit: hunterlabs (Ping timeout: 272 seconds)
17:46:32 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-rzinfzojmsjpmsoh) joined #osdev
17:50:18 --- join: dustinm` (~dustinm@68.ip-149-56-14.net) joined #osdev
17:56:36 --- nick: multi_io_ -> multi_io
18:04:19 --- quit: hunterlabs (Ping timeout: 252 seconds)
18:08:48 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-xvzhwuuweuvvnusc) joined #osdev
18:12:44 --- join: oaken-so1rce (~oaken-sou@p3E9D35CA.dip0.t-ipconnect.de) joined #osdev
18:15:52 --- quit: oaken-source (Ping timeout: 252 seconds)
18:16:28 --- join: c_ (~c@171.117.129.97) joined #osdev
18:16:45 --- nick: c_ -> Guest2729
18:27:07 --- quit: daniele_athome (Ping timeout: 264 seconds)
18:27:42 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
18:29:31 --- quit: Guest2729 (Ping timeout: 264 seconds)
18:43:13 --- quit: zng (Ping timeout: 265 seconds)
18:48:06 --- quit: John__ (Read error: Connection reset by peer)
18:49:48 --- quit: uvgroovy (Quit: uvgroovy)
18:52:23 --- join: awang_ (~awang@64.128.67.198) joined #osdev
19:09:45 --- quit: Belxjander (Ping timeout: 252 seconds)
19:12:23 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
19:19:10 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
19:21:43 --- quit: freakazoid0223 (Ping timeout: 264 seconds)
19:24:04 --- quit: fujisan (Quit: Connection closed for inactivity)
19:40:14 --- quit: zwliew (Quit: Connection closed for inactivity)
19:45:58 --- quit: jack_rabbit (Ping timeout: 248 seconds)
19:51:14 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
19:53:10 --- part: Redfoxmoon left #osdev
20:03:02 --- quit: jack_rabbit (Ping timeout: 248 seconds)
20:03:40 --- quit: Nach0z (Ping timeout: 252 seconds)
20:06:15 --- quit: Belxjander (Ping timeout: 248 seconds)
20:08:58 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
20:15:29 --- quit: tacco\unfoog ()
20:15:30 --- join: Nach0z (~nach0z@c-24-126-182-195.hsd1.ga.comcast.net) joined #osdev
20:15:31 --- quit: Nach0z (Changing host)
20:15:31 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
20:19:48 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
20:20:07 --- quit: Nach0z (Ping timeout: 248 seconds)
20:21:31 --- join: Philpax (~Philpax@n175-34-22-195.sun1.vic.optusnet.com.au) joined #osdev
20:27:49 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
20:33:38 --- quit: Philpax (Ping timeout: 260 seconds)
20:39:43 --- quit: awang_ (Ping timeout: 264 seconds)
20:46:33 <Love4Boobies> Oh, I remembered who the other QEMU dev was. Kevin. Not sure what the exact nickname was.
20:46:39 <Love4Boobies> Perhaps it was kevin.
20:48:52 --- quit: garit (Ping timeout: 272 seconds)
21:07:34 --- quit: jack_rabbit (Ping timeout: 248 seconds)
21:11:48 <doug16k> most of the time that rep outsb works. I don't see what's special about that one case, yet
21:12:03 <doug16k> I spent too much time on that already, but I'll go back and see if I can narrow it down soon
21:24:30 --- quit: Belxjander (Ping timeout: 252 seconds)
21:26:31 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
21:27:05 --- quit: freakazoid0223_ (Quit: A fine is a tax for doing wrong. A tax is a fine for doing well.)
21:27:56 --- join: aosfields_ (~aosfields@2607:fb90:2788:7e30:d563:5f9:e616:ac7c) joined #osdev
21:30:32 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
21:38:21 --- join: Pessimist (~Pessimist@78-62-89-218.static.zebra.lt) joined #osdev
21:38:21 --- quit: Pessimist (Changing host)
21:38:21 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
21:40:50 <geist> doug16k: so no luck yet?
21:41:15 <geist> that kind of smells like some sort of external corruption of the page table. perhaps print the page table entry at preciselyt he time it faults if you haven't already?
21:43:04 <doug16k> I did
21:43:14 <doug16k> https://gist.github.com/doug65536/07950a58aa66a2876e8dbcb0352a5737
21:43:16 <bslsk05> ​gist.github.com: gist:07950a58aa66a2876e8dbcb0352a5737 · GitHub
21:43:30 --- quit: aosfields_ (Ping timeout: 265 seconds)
21:43:45 <geist> yeah i saw that before
21:44:38 <doug16k> I put a breakpoint before that instruction, and set scheduler-locking on, so only that one cpu was stepped, then I stepped just that one cpu into the page fault handler
21:45:20 <geist> and what did you decide? it fails only after some time?
21:45:55 <latentprion> show me on the doll where it failed you
21:46:15 <heddwch> :D: best message 01/01/2018
21:46:17 <doug16k> oh I also did x commands to see the memory it was going to rep outsb, looked perfect. i checked rcx and dx, both correct
21:46:45 <doug16k> if there was something wrong with the page tables, the gdbstub wouldn't be able to show the string at $rsi
21:47:02 <geist> and rsi had the value in CR2?
21:47:07 <doug16k> yes
21:48:08 <doug16k> I get pointers to all 4 levels of the page tables for the fault address. I then made that gist from the page table entries in all 4 levels
21:48:28 <doug16k> I used info registers to confirm the cr2, and I got cr4 from there too
21:49:02 <geist> hmm, the CR4 does not have PSE set. i forget which one that one is precisely
21:49:12 <geist> has PGE and PAE
21:49:52 <geist> PSE is the 4MB/2MB page thing i think
21:50:35 <geist> but PGE is set
21:50:57 <heddwch> doug16k: What is your test platform?
21:51:02 <doug16k> PSE only applies to 32 bit paging according to the intel manual
21:51:20 <doug16k> heddwch, linux ryzen qemu kvm
21:51:30 <geist> ah yes. i see. it says PAE overrides it
21:52:45 <heddwch> I don't have any properly insightful knowledge on what your exact problem is, but can tell you that qemu does dynamic translation whereas bochs does proper emulation, and so I always had much more useful output from the bochs debugger. I uneducatedly think that's a good place to start.
21:54:35 <Mutabah> heddwch: Iirc the issue here is qemu in emulation mode works, but KVM doesn't
21:54:43 <Mutabah> doug16k: No luck in the source?
21:54:49 <Mutabah> doug16k: Add a bunch of printfs?
21:54:56 <heddwch> With a slight aside that in a recent project, I needed to use early (<=4.0) windows NT, and qemu simply could not support 16-bit apps thereon. NTVDM.EXE always crashed on illegal operations on known-good 16-bit applications. Point being, bochs is slow and painful, but, er, works.
21:55:12 <heddwch> Mutabah: Ah, gotcha, hadn't perceived that subtlety.
21:55:14 <geist> i think this is all happening in the cpu, in SVM
21:55:25 <heddwch> =w SVM
21:55:33 <heddwch> ..sorry
21:55:42 <geist> AMD's version of VMX
21:56:05 <geist> in general i've bumped into it being pickier about reserved bits in page tables
21:56:27 <geist> doug16k: though it doesn't line up with wat the manual precisely says, but how about try removing the G bit from anything but the absolutely last level page table
21:56:34 <heddwch> f@ck, ca--
21:56:35 <geist> at best the manual says it's IGN in the intermediate levels
21:56:37 <heddwch> ah, ty, geist
21:56:55 <heddwch> I can't access https:// anything at this point -_-
21:57:51 <geist> but perhaps it's wrong, and that's what we do in zircon
21:58:05 <geist> we only set it at the terminal level
21:58:27 <heddwch> Everything without a spec is wrong.
21:58:42 <heddwch> So, ah, have fun with your 8086 ;) At least there's proof Smalltalk is possible.
22:00:30 <geist> same with dirty bit. the amd manual says IGN, but then guess there's no reason for it to be set
22:00:57 <geist> and actually the inner ones shouldn't be set unless you're explicitly setting them as such, which is a bit weird
22:01:07 --- quit: KidBeta (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:02:24 <heddwch> haha :(
22:02:46 <heddwch> Moral of the story: Target RPi because it's today's Apple II and you can find at least docs.
22:02:54 * heddwch hides under a rock before the attacks hit
22:02:55 <doug16k> geist, it can't be in the cpu - converting it to a loop that outb's each character individually works fine
22:03:05 <doug16k> the cpu has no problem with the page tables
22:03:15 <doug16k> it's the emulation of rep outsb that has a problem
22:03:39 <Mutabah> doug16k: Have you found the code that handles `rep outsb` in qemu?
22:04:07 <doug16k> Mutabah, I looked pretty hard, all I can find is TCG code. I can't find code that is clearly the vmexit handling
22:04:13 <heddwch> Really bad suggestion, because outsb should indeed work, but consider not using string instructions, since they're negatively optimized in modern archs?
22:04:31 <geist> doug16k: i bet that's done almost entirely in the kernel
22:04:47 <geist> iirc SVM does a fairly aggressive first level decode of in/out instructions
22:04:51 <doug16k> heddwch, in a vm it does one vmexit for rep outsb. it is drastically faster than vmexit for every character
22:05:03 <geist> yah
22:05:20 <heddwch> Not that the speed should be a problem, but they are kinda not to be encouraged, but with added debugging difficulties, I would simply try a different (set of) instructions and see if the issue persists.
22:05:45 <heddwch> doug16k: Ah, gotcha, that makes sense. Wasn't aware, so thanks for teaching me :)
22:06:32 <geist> doug16k: so it could be something if the rep outsb crosses a page boundary and the emulation (in the kernel i think) doesn't deal with it nicely
22:06:39 <doug16k> heddwch, but yeah on bare hardware, rep outsb isn't that great. outb sucks everywhere. rep outsb sucks less in vms :D
22:07:19 <heddwch> hehe
22:08:07 <doug16k> geist, I thought at first it would be in the kernel. then what? it delivers a bunch of individual outb's to qemu's emulation code?
22:08:18 <heddwch> I'd like to say mostly, but not fully formed thoughts at this point, yet what I'll claim I meant is that while using the ISA makes sense, we're all pretty f%*&ing stumped, and using different instructions will give you more data that somebody might recognize.
22:08:54 <doug16k> I could have sworn I saw some rep outsb unravelling code that delivers a bunch of I/O access calls to the emulated devices before, but I didn't find it today
22:09:34 <doug16k> geist, not saying you are wrong, just saying I have vague memory of something else, which could easily be mistaken
22:10:17 <heddwch> To be clear, geist tends not to be wrong, being responsible for >0.5 production kernels.
22:10:19 --- join: quc (~quc@87.116.237.223) joined #osdev
22:10:24 --- quit: Pessimist (Remote host closed the connection)
22:10:40 <doug16k> I should rebuild qemu with debug info and put a breakpoint in the top level vmexit handler and step it
22:10:54 <heddwch> I really, really recommend trying bochs.
22:11:00 <Kazinsal> Fuck it, do it on real hardware and hook up an ICE
22:11:02 <geist> doug16k: yeah
22:11:06 <doug16k> heddwch, works on bochs
22:11:16 <doug16k> heddwch, I am a bochs contributor :D
22:11:20 <heddwch> Well, dig the parts that fail on qemu on bochs :p
22:11:34 --- quit: Belxjander (Ping timeout: 248 seconds)
22:11:34 <geist> doug16k: yeah that would be interesting. if anything just to get familiar with how it pops out of the KVM ioctl
22:11:40 --- quit: floatleft (Ping timeout: 256 seconds)
22:11:42 <doug16k> geist, yeah
22:12:00 * heddwch bows out to the more experienced.
22:12:05 <geist> i think we were just talking about rep outs on the zircon hypervisor
22:12:13 <heddwch> Zircon?
22:12:15 <geist> something we'll have to emulate at some point, but i think we punt on rep versions of it
22:12:30 <Mutabah> heddwch: Fuschia
22:12:33 <heddwch> Sorry, I'd--
22:12:40 <geist> and so far i think linux doesn't seem to use it
22:12:45 <heddwch> Zircon isn't even purple D:
22:13:02 <heddwch> Sorry, I'd look it up, but I lack a browser with https* D:
22:13:03 --- join: floatleft (~floatleft@2.55.168.111) joined #osdev
22:13:05 <geist> since that's the primary thing that folks use with qemu/kvm i wouldn't be surprised if you just bumped into some sort of bug
22:13:28 --- join: xenos1984 (~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120) joined #osdev
22:13:31 <geist> either a combination of SVM based instruction decoding and/or qemu/KVM
22:13:38 <heddwch> But, you know, I'm so grateful to give up more cycles than I have to confirm that nobody's man in the middling my motherfucking encyclopedia pages -_
22:13:43 <geist> since all that crap is fiendishly complicated
22:14:02 <heddwch> Security is THE ONLY PRIORITY. Remember that when you fuck me sideways.
22:14:24 <Mutabah> heddwch: mitm, or just monitoring
22:14:47 <geist> https://fuchsia.googlesource.com/zircon/+/master/kernel/arch/x86/hypervisor/vmexit.cpp#268 hmm, not even sure where you pick out the rep thing
22:14:49 <bslsk05> ​fuchsia.googlesource.com: kernel/arch/x86/hypervisor/vmexit.cpp - zircon - Git at Google
22:14:52 <geist> perhaps VMX actually sets it as a bit?
22:14:59 <Mutabah> And even if you don't care if you're being monitored, you using https helps protect those who need protection from monitoring
22:14:59 <heddwch> Mutabah: Idec. I have a 66MHz very mildly superscalar processor, and would just like to not have to decrypt public knowledge =/
22:15:37 <doug16k> the cpu puts it in the vmcs IIRC
22:16:38 <geist> and SVM seems to have the same thing. if you have the AMD manual, it's on 15.10.2 'IN and OUT behavior'
22:16:41 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
22:16:46 <Kazinsal> Okay well on one hand chances are there are at least two SSL added and removed here points in your chain but that doesn't mean it's kosher to send passwords in unencrypted cleartext
22:16:46 <heddwch> If they want to monitor me downloading a Z85230 datasheet, I'm kinda effing good with that.
22:16:59 <geist> there's a bit for rep and the string version in the EXITINFO1 field
22:17:09 <heddwch> Mutabah: Not really.
22:17:39 <heddwch> Others that want to hide that they're using ZILOG CHIPS for NEFARIOUS PURPOSES? They ain't gonna decrypt some fucking blu-rays within the decade.
22:17:52 <Kazinsal> I think we all kind of decided that when the average pre-pay burner smartphone from a convenience store can do TLS 1.2 on the fly then TLS everywhere was not a problem at all
22:18:07 <Kazinsal> It's kind of like those dudes screaming about how systemd core dumps on their 486 because it doesn't have CPUID
22:18:09 <heddwch> Yea =/ I mean, you are right and reasonable.
22:18:10 <geist> doug16k: are you using weird DS/ES values at the time?
22:18:14 <heddwch> It feels wasteful to me.
22:18:42 --- quit: wcstok (Read error: Connection reset by peer)
22:18:49 <heddwch> But, hey, my 486 which is literally what I'm using, can interface with one of those burner phones simply enough if I get off my ass and write some things.
22:19:18 <heddwch> I do agree with you on the binary dumps, btw
22:19:38 <doug16k> geist, vol 3c, 27-13, page 3792 in combined manual, table 27-8
22:19:50 <Kazinsal> The point is a 486 is literally three decades old at this point
22:19:52 <geist> vol 3c of what?
22:20:06 <doug16k> intel manual
22:20:10 <doug16k> "Format of the VM-Exit Instruction-Information Field as Used for INS and OUTS"
22:20:12 <geist> yes, but you're on an AMD
22:20:16 <geist> SVM != VMX
22:20:18 <heddwch> "BINARY LOGS?! WHAT IS THIS, WINDOWS?!" If it were, would you really bitch about having a nice header definition and simple way of pulling it that's much faster than a goddamn awk script? No? Oh, sorry, fundamentalism. I forgot.
22:20:20 <doug16k> I know
22:20:27 <doug16k> I thought you mean intel for your project
22:20:29 <Kazinsal> A core dump is not a binary stored log
22:20:33 <geist> ah sure. okay
22:20:56 <Kazinsal> Also the systemd coredumping on 486 is because they assumed anyone would be running the packages on P6+
22:20:57 <geist> anyway, looks like in both intel and amd it's up to software to emulate the meat of the in/out instruction, and deal with rep
22:21:00 <doug16k> 15.10.2 in AMD manual
22:21:13 <doug16k> pg 514 of system manual
22:21:22 <heddwch> Kazinsal: But an ARM Cortex-M is not three decades old, and carries about the same capability. There is no reason a basic MID should not be able to half-ass some HTML, but it can't because the crypto would take it four years to decode _public information_
22:21:24 <geist> it will nicely decode it for you, but otherwise it's your problem. so then the question is when it does the memory reference in in/out what code does that? does something have to manually parse the page tables?
22:21:49 <geist> the string versions seem like it'd have to, vs the regular in/out which only is moving to/from a register
22:21:57 <heddwch> Nobody bitches that posters on a bulletin board are insecure, but unfortunately, most software engineers have literally never seen a public bulletin board =/
22:22:37 <Kazinsal> Why are you trying to browse the web on a microcontroller?
22:23:13 <doug16k> the address is implied by the direction. outsb always uses rsi, insb always uses rdi
22:23:15 <Mutabah> heddwch: But people do get antsy when there's a person constantly watching and noting everyone who looks at a notice
22:23:25 <geist> doug16k: so from looking at this, it appears that ins/outs is actually fairly substantially more complex to emulate than a regular in/out
22:23:33 <geist> because in/out has no implicitly memory reference
22:23:37 <doug16k> yeah
22:23:39 <doug16k> exactly
22:23:47 <geist> that's probably why we haven't emulated it yet :)
22:25:19 <heddwch> Kazinsal, Mutabah: Let's shift frames to the ARMv4 microcontroller I have on my barcode scanner at work, running "real" Linux (not uClinux).
22:25:28 <heddwch> Am I supposed to use it for anything useful? Nope.
22:25:39 <Kazinsal> The modern internet isn't designed in any way whatsoever to run on a 33 MHz microcontroller with a two digit amount of SRAM and that's not the fault of the five nines of people who aren't attempting to use the modern web on that kind of "setup"
22:25:59 <heddwch> Do I? Yep. Could it be more useful if people weren't worried about somebody MITMing me and proving false information about McDonald's? Yep.
22:26:21 <Kazinsal> I'm genuinely confused as to what you're trying to accomplish
22:26:26 <heddwch> Would it hurt anything if the barcode scanner gave me wrong data on the price of a McChicken? Fuck the hell no.
22:26:40 <heddwch> Kazinsal: Living life. Without restrictions for somebody else to feel safe.
22:27:00 <Kazinsal> You're trying to download Zilog datasheets on a barcode scanner?
22:27:14 <Mutabah> So... you're complainin that you're forced over to https?
22:27:39 <Kazinsal> Forced to use TLS to download Zilog datasheets on a barcode scanner.
22:27:43 <heddwch> If I can spend $5 on a uC that's fully capable, then yes. If I have to spend $50 on a uC that's "safe" for a 2kb program based on a public spec, well
22:27:48 <heddwch> that's fucking stupid.
22:28:15 <Kazinsal> Honestly? What's fucking stupid is trying to use a $5 microcontroller for general computing and hooking up to the modern internet
22:28:16 <Mutabah> ... I'm not seeing the root of the argument
22:28:29 <heddwch> Kazinsal: Why? $5 not good enough?
22:28:33 --- quit: Belxjander (Ping timeout: 260 seconds)
22:28:44 <heddwch> Sorry, I'll try to join your social rank before I die, I promise.
22:28:48 <geist> doug16k: well, i guess stupid as invaded the channel. looks like you're getting close!
22:29:14 <Kazinsal> I'm almost 100% certain you could find an actual computer that can do TLS for five dollars used
22:29:33 <Kazinsal> You're trying to use a *microcontroller* for *general purpose computing*
22:29:47 <heddwch> Barcode scanner's not a practical example, sure.
22:29:50 <Mutabah> heddwch: Could you please restate the root of your argument here?
22:29:54 <geist> main problem with TLS on microcontrollers is the code size. i've personally had to deal with it
22:29:57 <heddwch> All right, buy a CPU for $5
22:30:07 <geist> and naively porting modern SSL and whatnot is pretty damn big
22:30:07 <heddwch> Please tell me what architecture you end up with.
22:30:10 <geist> like hundreds of KB
22:30:18 <heddwch> No company bulk discounts allowed, btw.
22:30:25 <geist> but at the end of the day a cortex-m class machine can easily do it
22:30:29 <geist> just not real fast
22:30:41 <geist> but not unnecesssarily slow. and probably would run rings around a 486
22:30:47 <heddwch> Not real fast would be okay, but yes, I am trying to allow for 16-bit addressing.
22:30:53 <geist> the multiplier probably kicks the shit out of a 486
22:31:05 <heddwch> With an MMU, obviously. 64k total ain't gonna do it.
22:31:14 <geist> or a 32bit machine, like a cortex-m is
22:31:26 <geist> but you need a big one, one with say 256 or 512KB of flash. which is no big deal
22:31:48 <geist> at some point for some project we had one of the SSL libs ported to LK on a cortex-m3. worked fine
22:31:49 <heddwch> Right. Please converse with me. Passive aggressively attacking me by cutely using the word stupid to others won't help a lot, but I do know you were right if you lacked the hubris.
22:31:51 <geist> was just ig
22:31:59 <geist> big even
22:32:59 <heddwch> My point is simply that if only 1m transistors are needed to pull a static page from a short distance, why should we just throw 10m at it ignoring cost and power just so it can encrypt the contents so the public knowledge is encoded at one end and decoded at the other end to still be public?
22:33:06 <geist> i was actually having to deal with https a bit on a sparcstation a few months back. man you really feel it there
22:33:14 <heddwch> yea =/
22:33:16 <Kazinsal> Found one for $5 on a local board that seems to have some kind of 266 MHz Pentium II in it
22:33:16 <geist> even sshing in takes a good 10-15 seconds to authenticate
22:33:18 --- join: KidBeta (~textual@220-244-156-86.tpgi.com.au) joined #osdev
22:33:39 <heddwch> Oh, ssh is the worst lol I've gerry-rigged https when I'm desperate, but SSHv2 is slower.
22:33:48 <Kazinsal> That's probably a bit slower than I'd like for TLS 1.2 though, let's see
22:33:50 <geist> but it is the price of things nowadays. stuff is encrypted
22:33:51 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev

22:34:01 <heddwch> I don't care about nowadarys.
22:34:15 <geist> same with compressed. trying to view a man page on a 50mhz machine that's bzip2 compressed or whatnot is not fun
22:34:27 <heddwch> Nowadays we throw 30m cycles at 500,000 cycle problems and think nothing of it, but that doesn't make it useful.
22:35:04 <geist> so it goes. however, i also use a lot of older machines from the 70s and 80s for nostalgia purposes
22:35:05 <Kazinsal> Several DD-WRT hackable modems for five bucks, pretty sure those will do TLS no problem
22:35:18 <geist> and it feels like 'oh man we dont need this fast shit' but really, it was kind of the pits back then
22:35:34 <geist> ie, the amount of stuff you can get accomplished in a much faster time with modern stuff is hard to express
22:35:34 <Mutabah> geist: I tried to get an ARM2 machine to play an audio rickroll, didn't go well :D
22:35:45 <Kazinsal> Plus you get to have the smug goodfeel of hacking some weird old modem to serve as a TLS proxy for you
22:35:55 <heddwch> kes: Thanks <3 To be fair, I am using sub-uC hardware, but it should not be hard to read a single text article about a pertinent topic. If someone somehow hi-jacks my ISP and replaces everything with subtly wrong information... well, first of all, that's not going to happen. It'll be fully wrong and trying to tell me to connect everything to Cambodia.
22:35:58 <geist> for example this 8080 machine i have with CP/M on it. it has a C compiler, what else could you need?
22:36:15 <geist> well, it takes a good 15 seconds to start a text editor, then 10 to save the file, then about a minute to compile and link
22:36:26 <heddwch> Kazinsal: Hard to compute on a DD-WRT fuckmodem. Not so hard on a 486 :p
22:36:29 <geist> all of that takes a second on a modern machine, almost completely gated by human operator speed
22:36:32 <Mutabah> heddwch: For the record - I agree that _forcing_ https is a bad idea
22:36:59 <heddwch> geist~3: I sorta disagree
22:37:10 --- quit: promach_ (Ping timeout: 272 seconds)
22:37:27 <heddwch> Mutabah: That's my only issue, yea. As far as allowing it, absolutely yes, universally, if you have the funds to do so.
22:37:37 <geist> obviously depends on the task at hand, but for raw software development speed, modern setups are many many orders of maginitude more productive
22:37:46 <Kazinsal> I force HTTPS because I don't want some jackwagon using HTTP non-S, getting MITMed, and causing a security breach
22:38:00 <heddwch> Which isn't hard. I pay $13 a month for a nice VPS capable thereof, but I'm at the bottom end of a first world country. We are fucking the world.
22:38:02 <Mutabah> heddwch: Suggesting it, defaulting to it - all good
22:38:17 <geist> i like to force https on client side because i set around in coffee shops with open wifi all the time
22:38:24 <heddwch> Say you have 20Ah a month without fucking the irrigation pumps and $0.50 disposable income.
22:38:31 <geist> i'd love for someone to finally generically solve some sort of tunneled dns thing too
22:38:53 <geist> short of a VPS like thing, which i use from time to time
22:41:14 --- join: osa1 (~omer@213.14.66.114) joined #osdev
22:41:14 --- quit: osa1 (Changing host)
22:41:14 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
22:41:31 --- quit: Belxjander (Ping timeout: 264 seconds)
22:43:48 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
22:50:08 --- quit: k (Ping timeout: 260 seconds)
22:51:46 --- join: kg (~krok@unaffiliated/krok) joined #osdev
22:54:16 --- quit: Belxjander (Ping timeout: 272 seconds)
22:58:08 --- quit: floatleft (Ping timeout: 256 seconds)
22:58:51 --- join: floatleft (~floatleft@2.55.20.229) joined #osdev
22:59:28 --- join: garit (~garit@94.197.120.198.threembb.co.uk) joined #osdev
22:59:28 --- quit: garit (Changing host)
22:59:28 --- join: garit (~garit@unaffiliated/garit) joined #osdev
22:59:32 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:01:49 --- quit: hunterlabs (Ping timeout: 265 seconds)
23:06:29 --- join: dengke (~dengke@106.120.101.38) joined #osdev
23:08:52 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-wtsgssgdarpmzuzq) joined #osdev
23:09:25 --- nick: oaken-so1rce -> oaken-source
23:12:35 --- join: navidr (uid112413@gateway/web/irccloud.com/x-qzrpfydstcwocgto) joined #osdev
23:16:02 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-xiwefdhwfqoywrhe) joined #osdev
23:16:12 --- join: promach_ (~phung@155.69.205.165) joined #osdev
23:23:34 --- quit: osa1 (Ping timeout: 248 seconds)
23:26:50 --- quit: Belxjander (Ping timeout: 240 seconds)
23:29:11 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:39:28 <graphitemaster> :D http://www.ex-parrot.com/pete/upside-down-ternet.html
23:39:29 <bslsk05> ​www.ex-parrot.com: Upside-Down-Ternet
23:40:15 <geist> graphitemaster: didja see the KAISER discussino on fuchsia? guess is it's a speculative execution read-from-kernel sploit
23:40:29 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
23:41:19 <graphitemaster> geist, no
23:41:44 <graphitemaster> I remember some video which was meh
23:41:48 <geist> https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/ is a good attempt
23:41:49 <bslsk05> ​cyber.wtf: Negative Result: Reading Kernel Memory From User Mode – cyber.wtf
23:42:07 <geist> but if some variant of that actually works... then you gotta unmap kernel space while user is running...
23:42:48 <graphitemaster> think it's safe to assume that kernel isolation is an impossibility given all the recent papers
23:43:01 <geist> hence the push to just keep it unmapped while user is running
23:43:16 <graphitemaster> nawh, someone found another exploit when when the kernel unmaps it
23:43:24 <geist> apparently there's an ARM patch to do the same thing, with PCID (x86) and ASID (arm) it's not as expensive as it could be
23:43:43 <Mutabah> :( we trust the CPU to do what we tell it to, and now we're learning that it doesn't
23:44:12 <geist> basically the gist is with modern cpus and speculative execution and lots of caches it's impossible to hide stuff like that
23:44:47 <izabera> fast or safe, pick one
23:45:13 <geist> trouble is of course mitigation solutions like this work even harder against syscall heavy microkernels like zircon :(
23:45:34 <graphitemaster> basically the biggest problems CPUs face now is side channel / timing attacks, if your isolation attempts can be observed this way they no longer work if given enough time and energy to actually follow through with one of those attacks, the last paper I read basically ended that the only way these things could be prevented is if CPUs took constant time for all memory accesses
23:45:35 <geist> i was hoping we were in the era of machines are fast enough that microkernels could realistically find a niche again
23:45:54 <graphitemaster> which sort of defeats the purpose of caches
23:46:24 <bcos> graphitemaster: 99% of these exploits depend on people ignoring Intel's "a secure OS will disable user-space access to TSC" advice that has been repeated for about 20 years now
23:46:55 --- quit: Belxjander (Ping timeout: 264 seconds)
23:47:06 <graphitemaster> bcos, there's still external exploits.
23:47:10 <geist> bcos: ARM has functionally the same thing now
23:47:12 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:47:21 <izabera> bcos: implying that you can't build a tsc-lookalike in userspace
23:47:36 <heddwch> s/cac(..)/brot\1l/gr
23:47:36 <Mutabah> ... you can't
23:47:39 <geist> the lack of TSC isn't a big deal with SMP now. the javascript based timing thing i was reading about just basically replicated TSC by having a second thread on another cpu act as the TSC
23:47:45 <heddwch> s/cac(..)/brot\1/gr
23:47:46 <izabera> Mutabah: prove it
23:47:46 <geist> by running some tight loop counter
23:47:55 <heddwch> whatever, fine enough
23:47:56 <Mutabah> Oh, what geist said...
23:48:00 <izabera> yeah
23:48:07 <Mutabah> Not quite as accurate... but yeah
23:48:11 <graphitemaster> geist, right and one of the mitigations against this is to light up CPUs with random bursts of kernel work that make it really difficult to time
23:48:28 <graphitemaster> basically add as much noise as possible while still staying fast
23:48:36 --- quit: jack_rabbit (Quit: Leaving)
23:48:44 <bcos> geist: Sure, but would be much less precise (e.g. not precise enough to measure things like speculative execution effects)
23:48:53 <geist> was enough for this particular sploit
23:49:02 <geist> actually pretty darn accurate from what i read
23:49:23 --- join: grawity (grawity@virgule.cluenet.org) joined #osdev
23:49:27 <graphitemaster> That's because the timing gap between hitting the speculative fast path and the fall back slow path is huge
23:49:59 <graphitemaster> The inaccuracies don't really matter then
23:50:21 <heddwch> s/ker(.)(.)./s\2m\2\1/gr
23:50:22 <geist> yah i'd assume if you could get within an order of magnitude or whatnot its probably good enough
23:50:36 <heddwch> bslsk05: wut
23:51:03 <heddwch> Must be set to logging only in here :p
23:51:23 <graphitemaster> Even then, if you avoid TSC Intel and AMD have a bunch of performance counters that you can use too, meaned for profiling code
23:51:31 <graphitemaster> many of them are not "protected"
23:51:48 <graphitemaster> Profilers like VTune for instance use them.
23:52:01 --- join: jack_rabbit (~jack_rabb@c-98-228-48-226.hsd1.il.comcast.net) joined #osdev
23:52:03 <heddwch> I'm gonna go get more booze
23:52:16 <graphitemaster> You could do a much better attack with those, they are far more accurate
23:52:18 <grawity> figured people here might know – where can I obtain (or how would I start making) a boot sector whose only job is to tell the BIOS to skip this disk and try another?
23:53:03 <geist> isn't just putting an invalid boot sector essentially that?
23:53:04 <Mutabah> I _think_ there's a bios call that tells it to try the next device in sequence... try looking at "Ralph Brown's Interrupt List"
23:53:13 <heddwch> =/ lolcat left? I don't see the message, but he's not in my /USERS
23:53:15 <Mutabah> Or that, having an unbootable disk should work
23:53:38 <geist> but then that probably involves not setting 55aa which i'm not sure is 'official' except in practice most bioses seem to test for it
23:53:55 <heddwch> I think there is, re: grawity, but I think the more important question needs to be here
23:53:59 <grawity> I'm not sure what makes a disk "unbootable", but having a completely blank bootsector (actually a GPT's "protective MBR" bootsector) and no "active" partitions didn't really help
23:54:26 <geist> yeah but did it have a 55aa thign at the end?
23:54:30 <heddwch> grawity: What are you trying to achieve? UEFI-only bootability?
23:54:39 <geist> if that's cleared out i wonder if that makes it skip?
23:55:09 <heddwch> Bad news: You can't rely on UEFI passage.
23:55:27 <grawity> heddwch: no; the system is BIOS, but the 1st disk is data-only, and I'm too lazy to open it up and swap cables around
23:55:48 <heddwch> If you want to boot, make a bootable UEFI setup. If you want to ignore your USB disk and boot the CD, don't make the USB disk bootable.
23:56:08 <heddwch> Gotcha, but why does that mandate your boot system?
23:56:21 <bcos> grawity: That's different then - if BIOS skipped the first hard drive it'd move on to other types of devices (CD, floppy, ...) and would still never try second hard drive
23:56:32 <heddwch> ^
23:57:03 <bcos> You could write a chain-loader though - MBR code on 1st drive that loads MBR on 2nd drive and jumps to it
23:57:04 <grawity> bcos: hmm, I can choose individual hard drives from the F8 boot menu so I figured it could do the same automatically
23:57:07 <heddwch> fucking state law
23:57:10 <doug16k> perf counters are MSRs which can only be configured in CPL 0
23:57:10 <grawity> heddwch: didn't quite understand the question
23:57:18 <grawity> geist: it does
23:57:30 <heddwch> be back in ~30m, or the damn stores are going to be disallowed re:booze
23:57:57 <grawity> actually I guess I'll dig around in the BIOS settings to see if I can rearrange individual disks in the boot order
23:58:17 <heddwch> grawity: It's okay, thankfully smart people are tring to help. If everything else fails, I'll be back in 30 minutes and we can waste a night forcing it :)
23:58:21 <bcos> ..but I wouldn't be too surprised if lots of people's MBRs are buggy (e.g. assume "boot device = 0x80" and ignore DL). Can fix that by hooking BIOS "int 0x13" and generic hackery
23:58:40 <graphitemaster> Can I ask why we're doing BIOS stuff instead of EFI?
23:58:43 <doug16k> grawity, if your bios is recent, play with the UEFI CSM settings (compatibility support module)
23:58:52 <geist> graphitemaster: read the problem statement
23:58:56 <doug16k> sometimes dinking around with that will enable it to boot the way you want
23:59:02 <grawity> geist: so if I removed that 0x55aa (which gdisk has automatically added), it would skip the disk entirely?
23:59:13 <heddwch> because it'll be another 6-10 years before BIOS stops being a reliable thing enterprise hardware uses because not UEFI
23:59:16 <geist> maybe? but then it may also break the partition table
23:59:17 <bcos> Hmm
23:59:27 <geist> so be prepared to put it back
23:59:35 <heddwch> ^^ grapheneslave
23:59:37 <bcos> grawity: Note that you wouldn't need to swap cables - usually there's "master/slave" jumpers on the drive :-)
23:59:52 <graphitemaster> there's also CS auto select :P
23:59:54 <grawity> not on SATA drives there isn't
23:59:59 --- log: ended osdev/18.01.01