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

Thursday, 4 January 2018

00:00:00 --- log: started osdev/18.01.04
00:02:38 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:15:52 --- quit: Belxjander (Ping timeout: 248 seconds)
00:21:26 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:26:38 --- join: xerpi (~xerpi@200.red-88-23-236.staticip.rima-tde.net) joined #osdev
00:27:21 --- join: eremitah_ (~int@unaffiliated/eremitah) joined #osdev
00:27:46 --- quit: xerpi (Remote host closed the connection)
00:28:09 --- join: xerpi (~xerpi@200.red-88-23-236.staticip.rima-tde.net) joined #osdev
00:30:07 --- quit: eremitah (Ping timeout: 264 seconds)
00:30:08 --- nick: eremitah_ -> eremitah
00:31:57 --- quit: zwliew (Quit: Connection closed for inactivity)
00:32:39 <immibis> __pycache__: if you browse the web, then no it is not safe to disable
00:35:25 --- join: srjek (~srjek@2601:249:601:9e9d:6d01:1b55:ae25:1e83) joined #osdev
00:36:09 <klange> Eh, you can mitigate attacks through web browsers in other ways.
00:36:29 --- quit: ahrs (Remote host closed the connection)
00:37:38 --- join: ahrs (quassel@gateway/vpn/privateinternetaccess/ahrs) joined #osdev
00:40:10 --- join: inode (~inode@unaffiliated/inode) joined #osdev
00:41:47 <immibis> actually, the vulnerability that AFAIK cannot be mitigated (which is spectre) has been demonstrated from javascript already, according to the paper
00:42:06 <klange> yes, and you can disable javascript :P
00:42:16 <Kazinsal> I mean that breaks a lot of the web
00:42:36 <Kazinsal> Best thing to do is run ubo and stop going to shady russian dungeon porn sites
00:42:45 <klange> Mozilla also seems to think reducing timer resolution may help
00:42:45 <Kazinsal> or throw your computer out the window
00:43:23 <bcos> If you disable javascript, companies won't know what sort of advertising you want.
00:44:07 <graphitemaster> geist, https://twitter.com/aionescu/status/948818841747955713
00:44:08 <bslsk05> ​twitter: <aionescu> This patch literally invents new computer science to work around the side-channel CPU issues. Continuing to be in awe and massive kudos to all the OS vendors who had to probably re-do entire feature roadmaps to handle this work. tl;dr Tokens/Processes now have "Security Domains". https://pbs.twimg.com/media/DSrhZXoU8AUnrt0.jpg
00:44:17 <graphitemaster> so MSRs to clobber BTBs
00:44:55 <graphitemaster> new BTB control bits :D
00:49:01 <graphitemaster> ARM gets CSDB (conditional speculation barrier)
00:49:06 <graphitemaster> so much new silicon already
00:49:55 <graphitemaster> very well written paper too https://armkeil.blob.core.windows.net/developer/Files/pdf/Cache_Speculation_Side-channels.pdf
00:50:50 --- quit: Belxjander (Ping timeout: 240 seconds)
00:53:07 <meowrobot> "Seems like old TRs from the Pentium days will be exposed soon"
00:53:14 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:53:14 <meowrobot> "old TRs from the Pentium days"
00:53:23 <meowrobot> "Pentium"
00:57:06 --- quit: osa1 (Remote host closed the connection)
00:59:50 <immibis> Kazinsal: use noscript and only enable it for reputable sites
01:00:40 <garit> 90% modern websites just wont work without js. Even wiki (wont show formulas\ math letters)
01:00:49 <immibis> so enable wikipedia then
01:01:03 <garit> You will have to manually enable every site you visit
01:01:14 <immibis> yes, once.
01:01:27 <garit> Internet is big enough for 'once'
01:01:34 <immibis> actually no
01:01:41 <immibis> you will have to manually enable every site that you trust to run javascript
01:01:48 <immibis> and for which you need the features that need javascript
01:02:13 <garit> most websited wont even give basic functionality without js
01:02:23 <immibis> you may be surprised how much stuff doesn't; also it uses the JS domain so stuff like disqus only needs to be enabled once
01:02:28 <immibis> garit: citation please. i used to use it
01:03:37 <Kazinsal> I mean clearly if you're going to sketchy bitcoin websites hosted in a closet in siberia you're in for a world of javascript hurt
01:04:55 --- join: Asu (~sdelang@AMarseille-658-1-118-132.w86-219.abo.wanadoo.fr) joined #osdev
01:07:32 --- join: glauxosdever (~alex@ppp-94-66-41-62.home.otenet.gr) joined #osdev
01:10:04 --- quit: quc (Remote host closed the connection)
01:10:17 --- join: quc (~quc@host-89-230-164-119.dynamic.mm.pl) joined #osdev
01:14:45 <garit> Kazinsal: why do i think about bitfinex when in read this
01:15:16 <Kazinsal> Because the idea of "sketchy bitcoin website hosted in a closet in siberia" describes 99% of cryptocurrency related entities
01:16:11 <garit> lol, true
01:17:14 <bcos> The other 1% are sketchy sites in closets in korea, india, china, ..
01:17:21 <bcos> ;-)
01:17:28 --- quit: hmmmm (Quit: Leaving)
01:18:53 <garit> but how do you even write stuff like bitfinex without js?
01:19:19 <garit> A form and sumbit button on every action and page reload?
01:19:53 <Kazinsal> The intersection of cryptocurrency fanatics and security paranoids is one such that their fanaticism will overload their paranoia and they'll turn javascript back on
01:21:07 <glauxosdever> Is security a paranoia though? I wouldn't think so (unless...?)
01:22:21 <immibis> garit: i don't know what bitfinex is, but the answer is yes?
01:22:38 <immibis> garit: or, if you trust bitfinex to use javascript responsibly, you whitelist it, which is 2 clicks
01:22:41 <Kazinsal> There are too many idiots on the internet who think they have an understanding of security and take that sliver of knowledge and extrapolate in ludicrous ways
01:22:47 <Kazinsal> And go full conspiracy paranoia
01:23:05 <Kazinsal> No, Javascript is not going to give AdSense your credit card numbers
01:23:18 <garit> immibis: i didnt see such sites for a long time (that dont use ajax and simikar stuff for partial page reload)
01:23:34 <immibis> it will, however, allow adsense to run bitcoin miners in the background
01:23:40 <immibis> or has*; I heard that was fixed
01:23:48 <glauxosdever> Kazinsal: Maybe because I haven't been reading many of such sites.
01:23:55 <glauxosdever> I don't know though.
01:24:02 <Kazinsal> Idiots like that are all over the internet
01:24:46 <glauxosdever> I wonder then why is it the first time I read about that then..
01:24:59 <glauxosdever> "Javascript is going to give AdSense ...."
01:25:36 <Kazinsal> People claim JavaScript is only used to transmit personal details to corporations and governments
01:25:57 <Kazinsal> Fun fact: Regardless of your JavaScript usage, the ad industry already has a massive profile on everyone.
01:26:13 <Kazinsal> Other fun fact: If a government wanted your deets they'd rubber hose them out of you
01:26:14 <glauxosdever> I've however yet to read such a claim.
01:26:58 <Mutabah> Kazinsal: But rubber hoses are tracable
01:27:04 <glauxosdever> Maybe because I don't read much of news or something.
01:27:17 <klange> reddit works fine without javascript, that's 99% of the interwebs
01:27:45 <Kazinsal> Mutabah: True. Tire irons are much more ubiquitous and more effective!
01:27:50 <Mutabah> klange: Well, the front page at any case :)
01:27:51 <glauxosdever> klange: IRC works fine without javascript, that's the rest 1%. :-)
01:31:49 --- join: sham2 (~sham1@dsl-tkubng22-58c1f8-5.dhcp.inet.fi) joined #osdev
01:31:54 --- part: sham2 left #osdev
01:33:29 --- join: sham2 (~sham1@dsl-tkubng22-58c1f8-5.dhcp.inet.fi) joined #osdev
01:33:56 --- quit: sham1 (Quit: WeeChat 1.9.1)
01:42:12 <z0ttel_> is css powerful enough to mine bitcoins by now?
01:42:37 --- quit: Arcaelyx_ (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:45:36 --- join: raph_ael (~raphael@2a00:dcc0:dead:a066:216:3cff:feae:868a) joined #osdev
01:49:15 --- join: Burgundy (~yyomony@84.232.222.54) joined #osdev
01:56:06 --- quit: oaken-source (Ping timeout: 248 seconds)
01:56:50 --- quit: Nach0z (Ping timeout: 240 seconds)
01:59:26 --- quit: courtc (Read error: Connection reset by peer)
02:02:37 --- quit: godel (Ping timeout: 252 seconds)
02:03:09 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
02:09:40 --- quit: raphaelsc (Remote host closed the connection)
02:10:13 --- join: oaken-source (~oaken-sou@141.89.226.146) joined #osdev
02:13:24 --- quit: puckipedia (Quit: *eh*)
02:13:24 --- quit: bslsk05 (Quit: woops)
02:17:49 --- join: zesterer (~zesterer@host86-169-20-84.range86-169.btcentralplus.com) joined #osdev
02:27:36 --- quit: Belxjander (Ping timeout: 248 seconds)
02:29:20 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
02:37:42 --- nick: sham2 -> sham1
02:42:18 --- join: puckipedia (~puck@irc.puckipedia.com) joined #osdev
02:43:17 --- join: bslsk05 (~bslsk@irc.puckipedia.com) joined #osdev
02:44:08 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-saatggqoppiekzes) joined #osdev
02:45:45 --- quit: nicdev (Remote host closed the connection)
02:53:22 --- join: garit2 (~garit@94.197.121.11.threembb.co.uk) joined #osdev
02:53:22 --- quit: garit2 (Changing host)
02:53:22 --- join: garit2 (~garit@unaffiliated/garit) joined #osdev
02:53:43 --- join: m_t (~m_t@p5DDA329B.dip0.t-ipconnect.de) joined #osdev
02:55:19 --- quit: garit (Ping timeout: 264 seconds)
03:04:28 --- quit: daniele_athome (Ping timeout: 240 seconds)
03:05:30 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
03:11:38 --- join: GautamS (~GautamS@59.182.251.47) joined #osdev
03:22:31 --- quit: caen23 (Ping timeout: 248 seconds)
03:29:46 --- quit: because (Ping timeout: 265 seconds)
03:31:45 --- join: because (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
03:37:03 --- quit: Belxjander (Ping timeout: 260 seconds)
03:37:50 --- quit: oaken-source (Ping timeout: 240 seconds)
03:38:50 --- join: oaken-source (~oaken-sou@141.89.226.146) joined #osdev
03:42:43 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
03:42:53 --- quit: garit2 (Ping timeout: 260 seconds)
03:47:41 --- join: garit (~garit@94.197.121.48.threembb.co.uk) joined #osdev
03:47:41 --- quit: garit (Changing host)
03:47:41 --- join: garit (~garit@unaffiliated/garit) joined #osdev
03:47:48 --- join: vmlinuz (~vmlinuz@2804:431:f724:dfcf:1eff:ada2:370b:8c9a) joined #osdev
03:47:48 --- quit: vmlinuz (Changing host)
03:47:48 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
03:48:51 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
03:53:19 --- quit: caen23 (Ping timeout: 255 seconds)
03:55:38 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
03:55:56 --- quit: xerpi (Quit: Leaving)
03:56:14 --- join: Nach0z (~nach0z@c-24-126-182-195.hsd1.ga.comcast.net) joined #osdev
03:56:14 --- quit: Nach0z (Changing host)
03:56:14 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
04:00:31 --- quit: caen23 (Ping timeout: 256 seconds)
04:02:01 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
04:03:02 --- quit: because (Ping timeout: 248 seconds)
04:05:33 --- join: because (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
04:06:14 --- quit: caen23 (Ping timeout: 248 seconds)
04:10:38 --- join: navidr (uid112413@gateway/web/irccloud.com/x-dekaxrsbkjahaxdl) joined #osdev
04:12:04 --- quit: Belxjander (Ping timeout: 250 seconds)
04:15:06 --- nick: Beato -> iIIuminati
04:17:26 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
04:26:19 --- join: dennis95 (~dennis@p50915F8C.dip0.t-ipconnect.de) joined #osdev
04:30:46 --- quit: bauen1 (Ping timeout: 248 seconds)
04:35:09 --- join: zng (~zng@ool-18ba49be.dyn.optonline.net) joined #osdev
04:36:29 <Levex> Hello #osdev!
04:36:38 <klange> Hello Levex!
04:40:26 <sham1> Hello Levex
04:40:57 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
04:46:26 --- join: bauen1 (~bauen1@ip5f5bfcbd.dynamic.kabel-deutschland.de) joined #osdev
04:47:25 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
04:48:30 --- join: rain1 (~user@unaffiliated/rain1) joined #osdev
04:53:50 --- quit: KidBeta (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
04:57:50 --- quit: pharaun (Ping timeout: 240 seconds)
05:02:28 --- quit: daniele_athome (Ping timeout: 240 seconds)
05:03:39 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
05:08:14 --- join: l0g0ut (~ekira@222.178.10.230) joined #osdev
05:18:54 <alexday> https://www.youtube.com/watch?v=k27B9MrKDWQ this is cool
05:18:56 <bslsk05> ​'Close-up: British Superbike Electronics' by 44Teeth (00:14:39)
05:26:58 --- quit: Belxjander (Ping timeout: 240 seconds)
05:30:27 --- join: awang_ (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
05:31:11 --- nick: multi_io_ -> multi_io
05:32:47 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
05:41:28 --- quit: mniip (Ping timeout: 240 seconds)
05:44:58 --- join: mniip (mniip@unaffiliated/mniip) joined #osdev
05:46:03 --- quit: l0g0ut (Remote host closed the connection)
05:46:24 --- join: l0g0ut (~ekira@222.178.10.230) joined #osdev
05:51:24 --- quit: l0g0ut (Remote host closed the connection)
05:51:40 --- join: l0g0ut (~ekira@222.178.10.230) joined #osdev
05:52:10 --- quit: ahrs (Remote host closed the connection)
05:52:55 --- part: l0g0ut left #osdev
05:53:19 --- join: ahrs (quassel@gateway/vpn/privateinternetaccess/ahrs) joined #osdev
05:55:00 --- join: NotSecwitter (~NonSecwit@unaffiliated/nonsecwitter) joined #osdev
05:55:42 --- quit: NotSecwitter (Max SendQ exceeded)
06:00:45 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
06:00:58 --- quit: promach__ (Read error: Connection reset by peer)
06:01:19 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
06:02:10 --- quit: promach__ (Remote host closed the connection)
06:04:41 --- join: John__ (~John__@79.97.140.214) joined #osdev
06:04:55 --- quit: oaken-source (Ping timeout: 264 seconds)
06:10:13 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
06:12:48 --- join: NotSecwitter (~NonSecwit@unaffiliated/nonsecwitter) joined #osdev
06:22:05 --- quit: awang_ (Ping timeout: 268 seconds)
06:22:43 --- quit: MrOlsen (Read error: Connection reset by peer)
06:25:26 --- quit: ziongate (Ping timeout: 248 seconds)
06:25:42 --- quit: daniele_athome (Ping timeout: 265 seconds)
06:26:34 --- join: MrOlsen (~reddawg@Pub.SpherePBX.com) joined #osdev
06:27:30 --- quit: sigjuice (Ping timeout: 272 seconds)
06:27:50 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
06:28:03 --- join: ziongate (~angelo@mittelab/members/ziongate) joined #osdev
06:29:40 --- join: sigjuice (~sigjuice@107.170.193.86) joined #osdev
06:31:28 --- quit: voidah (Ping timeout: 260 seconds)
06:37:45 --- join: oaken-source (~oaken-sou@p3E9D3430.dip0.t-ipconnect.de) joined #osdev
06:37:48 --- join: awang_ (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
06:38:43 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
06:47:21 --- join: voidah (~voidah@unaffiliated/voider) joined #osdev
06:57:57 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
07:04:45 --- join: uvgroovy (~uvgroovy@199.188.233.130) joined #osdev
07:23:49 --- quit: dhoelzer (Ping timeout: 252 seconds)
07:23:58 --- quit: farb (Ping timeout: 240 seconds)
07:24:06 --- join: Retr0id (~Retr0id@unaffiliated/retr0id) joined #osdev
07:25:47 --- quit: GautamS (Read error: Connection reset by peer)
07:30:35 --- join: pictron (~tom@pool-173-79-33-247.washdc.fios.verizon.net) joined #osdev
07:30:39 --- join: GautamS (~GautamS@59.182.243.247) joined #osdev
07:33:10 --- join: hmmmm (~sdfgsf@pool-72-79-161-183.sctnpa.east.verizon.net) joined #osdev
07:33:22 --- quit: zwliew (Quit: Connection closed for inactivity)
07:35:57 --- quit: xenos1984 (Quit: Leaving.)
07:37:15 --- quit: variable (Quit: Found 1 in /dev/zero)
07:38:16 --- join: m3nt4L (~asvos@2a02:587:a019:8300:3285:a9ff:fe8f:665d) joined #osdev
07:38:57 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-himepbbltlcftrwg) joined #osdev
07:40:25 --- part: rubenwardy left #osdev
07:46:05 --- join: tacco\unfoog (~tacco@dslb-084-057-127-104.084.057.pools.vodafone-ip.de) joined #osdev
07:50:17 --- quit: Humble (Ping timeout: 265 seconds)
07:55:34 --- quit: heat (Ping timeout: 240 seconds)
07:58:50 --- join: Humble (~hchiramm@2405:204:d409:4aee:ed60:203d:492d:7ad3) joined #osdev
07:59:02 --- quit: navidr (Quit: Connection closed for inactivity)
08:01:23 --- join: multi_io_ (~olaf@x4db368b5.dyn.telefonica.de) joined #osdev
08:02:30 --- quit: caen23 (Ping timeout: 256 seconds)
08:02:33 --- join: gdh (~gdh@2605:a601:639:2c00:884a:2536:4f7c:82cf) joined #osdev
08:04:46 --- quit: multi_io (Ping timeout: 256 seconds)
08:05:06 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
08:07:01 --- join: raphaelsc (~utroz@187.114.6.255) joined #osdev
08:12:58 --- quit: raphaelsc (Ping timeout: 240 seconds)
08:13:34 --- quit: zesterer (Quit: zesterer)
08:15:43 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
08:16:04 --- join: zesterer (~zesterer@host86-169-20-84.range86-169.btcentralplus.com) joined #osdev
08:25:11 --- join: raphaelsc (~utroz@179.179.230.39) joined #osdev
08:29:24 --- join: azonenberg_work (~azonenber@172.58.201.146) joined #osdev
08:29:30 <azonenberg_work> Hmm, random fun idea
08:29:48 <azonenberg_work> CPU that skips branch prediction and uses two execution units to speculatively execute both paths of a branch simultaneously
08:30:00 <azonenberg_work> thus ensuring 100% prediction accuracy (at the cost of a bit more I-cache bandwidth)
08:30:27 <azonenberg_work> So basically, rather than dual issuing two instructions from a guessed branch path until you know which way to go
08:30:27 <Love4Boobies> So essentially, you're paying for more resources than you get to use.
08:30:36 <azonenberg_work> single-issue one instruction from each path
08:31:01 <azonenberg_work> the theory being, most ALU instructions are pretty cheap (you could stall if the speculated path hits a FPU insn or something)
08:31:03 <Love4Boobies> Also, you only get a little bit of a boost for the very first instruction after which you're out of execution units.
08:31:05 <azonenberg_work> so having a couple extra integer units are cheap
08:32:20 <azonenberg_work> Well, the idea is to avoid a misprediction penalty
08:32:29 <azonenberg_work> by ensuring that you always guess right
08:32:38 <azonenberg_work> kinda like the hypothetical nondeterministic Turing machine
08:32:42 <Love4Boobies> What happens if you have two branches in sequence?
08:32:47 <azonenberg_work> Then you have to stall or guess
08:33:02 <Love4Boobies> Guessing is what speculative execution is, basically.
08:33:24 <Love4Boobies> It's just that they skip the extra execution unit because it's expensive and barely offers anything.
08:33:53 --- join: Darmor (~Tom@198-91-187-5.cpe.distributel.net) joined #osdev
08:34:08 <Love4Boobies> Also, it isn't enough to just have an extra ALU. You need an extra execution unit of each type.
08:34:27 <Love4Boobies> And most of those resources will be sitting around idle most of the time.
08:35:36 <azonenberg_work> Well no, speculation involves guessing and starting to execute the predicted path
08:35:43 <azonenberg_work> i dont think they usually execute both paths at once
08:36:00 <azonenberg_work> and you dont need every type, you just need the most common types of instructions
08:36:06 <Love4Boobies> ...
08:36:10 <azonenberg_work> If you cant speculate vector instructions, thats not the end of the world
08:36:17 <azonenberg_work> you just dont gain performance from this
08:36:18 <Love4Boobies> <Love4Boobies> What happens if you have two branches in sequence?
08:36:26 <Love4Boobies> <azonenberg_work> Then you have to stall or guess
08:36:41 <azonenberg_work> (also gotta run, bakc later)
08:37:01 <Love4Boobies> You're already out of execution units, we were talking about the case where you can't continue executing in parallel.
08:37:14 <Love4Boobies> Also, look at hyperthreading.
08:37:25 <Love4Boobies> Even for separate threads they can't do a very good job filling the pipeline.
08:37:43 <Love4Boobies> Imagine the waste that would be going on for single threads.
08:39:01 <doug16k> if branch prediction was usually 50% success, then going both ways will be a win. it is much much more successful than 50% though
08:39:03 <Love4Boobies> (I realize SMT uses the same execution unit and different register files)
08:40:03 <Love4Boobies> doug16k, the proposal is for 100% but only once in a very long while. I don't think it's worth it.
08:40:32 <Love4Boobies> You basically need a whole lot of extra execution units, not just an extra set.
08:40:54 --- quit: azonenberg_work (Ping timeout: 248 seconds)
08:40:58 <doug16k> I vaguely remember hearing about an architecture that did go both ways in an EE CPU architecture lecture. I wish I remembered what it was
08:41:25 <doug16k> probably something obscure though
08:41:26 <Love4Boobies> But branches that lead to other branches screw everything up.
08:41:30 <Love4Boobies> And that's a very common code pattern.
08:41:34 <doug16k> ya
08:43:22 <doug16k> if you want it to go both ways, write branch free code, execute both sides of the condition, and merge the proper path into the result with bitmasks. this is often done on gpus
08:43:51 --- join: vaibhav (~vnagare@125.16.97.121) joined #osdev
08:44:35 <xenos1984> also there is MOVcc on x86 for this purpose
08:44:44 <Love4Boobies> There's a little bit of support fo that in
08:44:49 <Love4Boobies> Yeah, was going to say that.
08:45:27 <doug16k> xenos1984, yeah, for the simpler case, movcc is good. for more elaborate cases, masking things is more flexible
08:45:42 <xenos1984> i like what MIPS is doing - the instruction following a branching instruction is always executed, and the actual branch happens after that instruction
08:46:09 <xenos1984> that makes the pipeline easier, but must be taken into account in code design
08:47:34 <xenos1984> if you can't put anything useful after the branching instruction, that should be executed in any case, you have to put a nop
08:47:36 <doug16k> xenos1984, that exposes the microarchitecture to the code though. if you change the pipeline such that you need a different number of branch delay slots, then you are back to needing hazard detection
08:48:57 <xenos1984> doug16k: indeed, but i think it's part of the MIPS ISA definition that there is only one delay slot (which of course then limits the pipeline)
08:49:05 <doug16k> it's also a pain for compiler's scheduling pass
08:49:50 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
08:50:14 <doug16k> generally you can bump two instructions from before the delay slot to after the branch, but which two? you need to figure out which ones can be moved by flow analysis and if it's too close to the beginning of a basic block, you fall back to nops
08:50:29 <doug16k> pain
08:50:56 <doug16k> is it one? I thought it was two
08:51:33 <xenos1984> hm... IIRC one in MIPS, but i might be wrong
08:54:32 <doug16k> oh, the reason why masking can be better than conditional moves is, movcc requires the flags to be set. you may need to repeatedly do the compare to setup the flags. if you use masks, you can do the compare and generate masks once up front, then repeatedly use the masks
08:54:37 --- join: dhoelzer (~dhoelzer@ool-4a5940e5.dyn.optonline.net) joined #osdev
08:56:40 <doug16k> using masks also puts a gun to the compiler's head. if you use the conditional operator it might end up generating branches, defeating your optimization
08:58:17 <doug16k> branch free code is absolutely amazing in sort callbacks, where branches are totally unpredictable. if you are doing a multi-level sort that needs to go as fast as possible, then you need branch free comparer
09:04:59 --- join: millerti (~millerti@cpe-66-24-91-119.stny.res.rr.com) joined #osdev
09:05:57 --- quit: Belxjander (Ping timeout: 252 seconds)
09:06:29 --- join: Arcaelyx (~Arcaelyx@2601:646:c200:27a1:4927:8c58:8677:9893) joined #osdev
09:07:48 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
09:15:06 <heat> https://twitter.com/aionescu/status/948818841747955713
09:15:07 <bslsk05> ​twitter: <aionescu> This patch literally invents new computer science to work around the side-channel CPU issues. Continuing to be in awe and massive kudos to all the OS vendors who had to probably re-do entire feature roadmaps to handle this work. tl;dr Tokens/Processes now have "Security Domains". https://pbs.twimg.com/media/DSrhZXoU8AUnrt0.jpg
09:15:28 <heat> looks like there will be new msr's to control the BTB
09:15:56 <ohnx> solution: have 2 separate computers, one to run untrusted code, and one to run trusted code :')
09:18:25 --- quit: m3nt4L (Remote host closed the connection)
09:30:31 <zesterer> ohnx: Or just implement PTI for untrusted processes, and allow verified binaries (i.e: verified signatures) to have kernel space mapped to them. Problem is, it adds an extra branch to the kernel trampoline (or requires you to flush the IDT when switching between trusted and untrusted processes)
09:30:38 <zesterer> Still doesn't fix Sceptre through :\
09:30:51 <ohnx> my solution "fixes" spectre
09:31:13 <heat> the new solution/nt solution fixes spectre afaik
09:31:28 <ohnx> and yeah, I guess kpti for untrusted is an interesting idea
09:31:40 <zesterer> ohnx: It's not exactly a good solution though. Using your credit card on literally any website suddenly becomes impossible (I'm sure some sort of webby javascript exploit for sceptre will appear)
09:31:56 <zesterer> heat: Oh? How?
09:32:15 <heat> they use the new MSR and fall back to a shitty trampoline if it isn't available
09:32:56 <heat> zesterer: By cobblering the BTB when the "Security Domain" changes
09:33:00 <zesterer> heat: Surely that only works for very new CPUs?
09:33:13 <heat> Yes, this is something new
09:33:46 <heat> we don't know if it's going to be a new cpu only thing or a microcode update that adds it(considering that this used to be an old pentium register)
09:33:58 <zesterer> I'm going to assume that Intel (and other vendors) started patching CPUs sometime last year when they heard about the bug?
09:34:11 <ohnx> zesterer: to be fair, lots of browsers are fixing up their javascript enginers
09:34:16 <ohnx> s/enginers/engines
09:34:23 --- join: Tobba (~Tobba@h-25-170.A159.priv.bahnhof.se) joined #osdev
09:34:45 <heat> This is a tiny bit of the trampoline windows is going to use: https://twitter.com/aionescu/status/948817335980142592
09:34:45 <bslsk05> ​twitter: <aionescu> The mitigations poor OS vendors have to do for "Variant 2: branch target injection (CVE-2017-5715)" aka #Spectre make me cry/die a little inside. https://pbs.twimg.com/media/DSrgLFZVwAAoov6.jpg
09:35:05 <zesterer> ohnx: Yet again, hardware issues are being patched with software when it really should be the chip vendor's job to check this stuff
09:35:09 <heat> apparently done at every trap/interrupt/thread start/syscall
09:37:06 <heat> zesterer: I don't think so, considering the bug still works on new CPUs
09:37:18 <zesterer> heat: For my lowly knowledge, can you give me a run-down on what that does? doing weird stuff to the stack, and jumping around a lot?
09:38:17 <heat> I'm not exactly the best person to answer your question but I would guess it cobbles the BTB by doing some fucked up branch shit
09:39:15 <zesterer> heat: Oh, right of course. I assume the BTB can only hold a limited number of potential branches? That's hack AF
09:39:21 <zesterer> *hacky
09:39:25 <heat> yes
09:39:47 <zesterer> How many more cycles does that require? calls are pretty expensive aren't they?
09:40:04 --- quit: quc (Remote host closed the connection)
09:40:09 <heat> meh, not that expensive
09:40:17 --- join: quc (~quc@host-89-230-164-119.dynamic.mm.pl) joined #osdev
09:40:38 <heat> but yes it will be rather slow vs the wrmsr
09:42:35 --- quit: jakogut (Read error: Connection reset by peer)
09:43:13 --- join: silas (~silas@177.104.48.3) joined #osdev
09:43:16 <zesterer> heat: Does this allow kernel memory to be mapped into userland tables? I assume since the only entry point to the kernel / ring 0 is the syscall handler, it means that the mapped memory remains safe?
09:44:01 <heat> yeah it should be safe
09:44:43 <zesterer> Safe from both meltdown and spectre?
09:45:18 <heat> I think so? Must be, considering that it's the only protection that NT has right now
09:45:27 <raphaelsc> has anyone come across a poc for meltdown?
09:46:10 <raphaelsc> i think it's more fun to do it myself following the ideas presented in the paper :-)
09:46:44 <heat> they do have a lot of code to detect the CPU's vulns to the different variants instead of assuming it's vulnerable like linux does
09:47:52 <zesterer> heat: Huh. I assume that will change soon though.
09:48:38 <zesterer> heat: Problem is, since Linux dev is open, most of the kernel community won't have been informed of the bug previously to prevent news spreading. The Microsoft team probably knew about this months ago and have had ages to patch it.
09:49:02 --- join: garit2 (~garit@94.197.121.122.threembb.co.uk) joined #osdev
09:49:02 --- quit: garit2 (Changing host)
09:49:02 --- join: garit2 (~garit@unaffiliated/garit) joined #osdev
09:49:43 <heat> Yeah but I doubt intel couldn't submit any kind of patch with these kinds of fixes
09:49:43 --- quit: garit (Ping timeout: 255 seconds)
09:53:22 --- quit: zwliew (Quit: Connection closed for inactivity)
09:53:38 <heat> llvm also got a new mitigation patch
09:53:44 <heat> https://reviews.llvm.org/D41723
09:53:47 <bslsk05> ​reviews.llvm.org: ⚙ D41723 Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..
09:54:34 <EvilRoey> bslsk05, heat, zesterer, raphaelsc: so what do these patches do, disable portions of speculative execution?
09:54:35 <rain1> I dont understand this
09:54:46 <rain1> are we supposed to compile the linux kernel with this patched llvm?
09:54:54 --- quit: Humble (Ping timeout: 252 seconds)
09:55:13 <zesterer> EvilRoey: Spam call instructions until the CPU branch pipeline is broken to prevent speculative execution
09:55:38 <EvilRoey> oh
09:55:39 <EvilRoey> uh-oh
09:55:59 <doug16k> heat, that bunch of calls overflows the return address stack. call is about 2 cycles
09:56:00 <EvilRoey> so when you say "spam call instructions", with what? no-ops?
09:56:38 <heat> rain1: Pretty sure you're supposed to compile your own apps with the patched llvm to protect against spectre
09:56:50 <rain1> oh okay this is for the other one
09:56:55 <bcos> EvilRoey: Like this: https://pbs.twimg.com/media/DSrgLFZVwAAoov6.jpg
09:56:56 <rain1> I am just reading about meltdown now
09:57:00 <EvilRoey> bcos: thank yo uso much
09:57:04 <raphaelsc> EvilRoey: https://lkml.org/lkml/2017/10/31/884
09:57:04 <bslsk05> ​lkml.org: LKML: Dave Hansen: [PATCH 00/23] KAISER: unmap most of the kernel from userspace page tables
09:57:44 <EvilRoey> raphaelsc: aye
09:58:04 <bcos> Has anyone seen documentation for Intel's new "BTB control MSR" stuff?
09:58:04 <doug16k> when the cpu executes a call, it stashes the return address in a return address stack. when it hits a ret, it pops from the return address stack and uses that to predict the return address. when the ret retires, it checks the actual return address and if it doesn't match, it is a mispredict. usually it does match and it is a correct ret prediction. those calls overflow that stack
09:58:22 <raphaelsc> bcos: nope, mind sharing?
09:58:33 * bcos hasn't found any documentation either :-(
09:58:49 <heat> bcos: it's mostly just new NT constants afaik, still under embargo
09:59:08 <EvilRoey> doug16k: got it
10:00:20 <heat> (PTI looks horribly slow compared to the call spam)
10:00:33 <bcos> It all looks horribly slow
10:00:59 <bcos> ..with luck, maybe some russian botnet will save us from the "malicious performance degredation" attacks from OS vendors.. :-)
10:01:51 <doug16k> does anyone know if there is an override to disable the workarounds, if you don't care about malicious code?
10:01:55 --- quit: NotSecwitter (Ping timeout: 264 seconds)
10:02:08 <bcos> (seriously, I'm going to assume that most users are going to be so annoyed with performance that they disable all this stuff)
10:02:09 --- join: Guest13020 (~lice@106.112.37.137) joined #osdev
10:02:17 <Kazinsal> Also LOL at all the shitty AV vendors whose products did awful things to the old NT syscall mechanism and bluescreen with the new KPTI trampoline
10:02:37 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
10:02:38 <Kazinsal> third party antivirus: not even once
10:03:00 <bcos> doug16k: For Linux there's a boot-time kernel option to disable PTI, and a compile-time option for the "retpolines"
10:03:17 <bcos> ..for Windows, no idea
10:03:19 <heat> Kazinsal: Huh? What did the AV vendors do?
10:03:43 <Kazinsal> Buncha AV vendors used to do bad things to monitor the NT syscall mechanism for injections
10:03:49 <doug16k> for windows, my wild guess is a bcdedit switch
10:04:07 <heat> I doubt windows will let you disable those workarounds
10:04:20 --- quit: freakazoid0223 (Ping timeout: 240 seconds)
10:04:20 <Kazinsal> These bad things now break the trampoline now and then -- not sure what, my assumption is stack frame corruption -- and bugcheck
10:06:09 --- join: user10032 (~Thirteen@2a02:c7d:314e:b300:8ac:33eb:bf6f:8788) joined #osdev
10:07:06 --- join: Humble (~hchiramm@2405:204:d20e:c1d6:8cc1:e44a:314:e56c) joined #osdev
10:07:22 <heat> Looks like MacOS took the linux approach to the problem by unmapping the kernel
10:07:59 <bcos> Intel's shiny new "Control-flow Enforcement Technology" isn't looking quite so promising..
10:08:34 <bcos> ("retpolines" completely break it)
10:08:54 --- join: NotSecwitter (~NonSecwit@unaffiliated/nonsecwitter) joined #osdev
10:13:16 <zesterer> bcos: Would be nice if it could be changed with an environment variable. I.e: "PTI_DISABLED=1 bash", with all child processes having PTI disabled too.
10:14:13 <heat> zesterer: The kernel isn't even aware of environment variables :>
10:14:22 <bcos> zesterer: So an attacker can just change an environment variable to disable PTI?
10:14:43 --- join: John___ (~John__@79.97.140.214) joined #osdev
10:14:54 <peterbjo1nx> you could have some process metadata about it that may only be set by uid=0
10:14:56 --- join: brkt (~quassel@177.69.179.225) joined #osdev
10:14:57 <zesterer> bcos: The OS would check upon starting the process, and it would be impossible to disable, even for child processes.
10:15:12 <peterbjo1nx> so that root can start a process tree that has it disabled
10:15:54 <zesterer> Okay, thinking about it further I see why that's a stupid idea :D
10:16:18 --- join: rubenwardy (~rubenward@unaffiliated/rubenwardy) joined #osdev
10:16:55 <zesterer> You'd have to have everything from init downwards possessing PTI_DISABLED=1, and then have some sort of system for automatically de-trusting any untrusted programs on launch, which sounds like something that needs to influence a lot of userland stuff
10:16:56 <Kazinsal> I've always been averse to the idea that root == god
10:17:04 --- quit: John__ (Ping timeout: 252 seconds)
10:17:10 <Kazinsal> Like, there are some mechanisms that root just should not be able to turn off
10:18:09 <bcos> I've reached the opinion of "root = untrusted janitor"
10:19:32 <bcos> (CEO of IBM has less authority than some dude that maintains an email server? WTF..)
10:19:40 <bcos> ;-)
10:20:17 --- quit: brkt (Remote host closed the connection)
10:22:39 <GautamS> Kazinsal, Well, then people would just request another feature called "superroot"
10:23:01 <Kazinsal> Closing feature requests due to security implications
10:23:22 <GautamS> Ha
10:23:40 <bcos> Principle of least privilege = figure out the things that root needs to do and don't let them read their bosses confidential files
10:24:02 <heat> unix people love feeling powerful though, that would never happen
10:24:52 <Kazinsal> Unix people can suck it or get off the modern threat-covered net
10:24:58 <GautamS> Yeah, I don't really see the problem with root being able to do everything unless I've missed something relevant to the discussion. You can always restrict root access.
10:25:19 --- quit: Darmor (Ping timeout: 252 seconds)
10:25:23 <Kazinsal> Ain't no place in a modern world for the administrator user account being able to do kernel grade shenanigans
10:25:36 <heat> (Although I admittedly love feeling powerful, I should never be able to disable important mitigations and security)
10:25:45 --- quit: zesterer (Quit: zesterer)
10:26:02 <GautamS> Haha, seems like everyone suffers from intrusive thoughts once in a while.
10:26:05 <Kazinsal> The problem with just restricting root access is that locks out the human element but not the exploit element
10:26:07 <doug16k> root can change the kernel source and compile a custom kernel that does as he pleases
10:26:25 <sham1> But let's be fair here. There is rationality behind having access to that kind of superuser access
10:26:34 <sham1> Sometimes you just have to do what you have to do
10:26:39 * bcos split it all up into "cluster owner", "infrastructure officer/s" and "security officer/s"
10:27:39 <heat> doug16k: the user can smash the hard drive into tiny bits - does that justify ignoring filesystem permitions?
10:27:57 <GautamS> Although I would like to see a feature like "superroot" or something similar. Often, you need privileges for very tiny tasks, and you don't want to mess up something critical.
10:28:23 <GautamS> Something like Ring0 vs SMM
10:28:25 <bcos> heat: Main concern is confidentiality - smashing hard drive improves confidentiality
10:28:28 <sham1> You ever heard of this tiny program called sudo. It can be made to only allow you to do certain tasks
10:29:06 <GautamS> Of course, I do. :)
10:29:19 <heat> fakeroot is pretty dope too
10:29:30 <sham1> Yeah
10:29:41 <MDude> A source of issues here seems to be that the computer has no idea why exactly a user has some level of authoirty over the local machine.
10:30:04 <doug16k> root is just an optimization. you can check one int. it's the software equivalent of checking CPL to see if an instruction is allowed
10:30:30 <MDude> You don't want to get treated like you're just managing the computer on someone else's behalf when you own it and it's sitting right there in your bed room.
10:32:08 <heat> tbf the whole unix account model(with gids and uids) is pretty stupid
10:32:10 <rain1> hello
10:32:23 <rain1> can you help me understand paging better for the meltdown bug. i have a question
10:32:25 <sham1> Ever for my personal home computer which only I use, I do still appreciate root. Having an account for dedicated system administration and fixing up mishaps is useful for me personally (I for one like to tinker with stuff)
10:32:48 <rain1> "Accessing user-inaccessible pages, such as kernel pages" in a user space linux process why can I attempt to access kernel pages?
10:32:49 <sham1> Could there be a better permission model? Sure.
10:32:54 <Kazinsal> The whole idea of SIDs is a lot more complex than the GID/UID thing but it's really handy in its uniqueness and inherent dependency chain
10:33:18 <sham1> By SIDs, do you mean security IDs?
10:33:22 <Kazinsal> Yeah
10:33:23 <_mjg> rain1: they are there for performance reasons
10:33:27 <Kazinsal> Like, I can take a SID and trace back the authorities that created that SID
10:33:39 <_mjg> rain1: the cpu is supposed to provide protection against user access
10:33:52 <rain1> why dont we map them to 0 values? then accessing themm will give 0
10:33:54 <_mjg> rain1: and if they are there, when you do syscalls there is less work to service them
10:33:54 <doug16k> uid and gid are the same thing, an optimization. check a couple of ints, bam, done
10:34:19 <rain1> hmm
10:34:21 <_mjg> not having them there is more work and that's why people are unhappy
10:34:37 <heat> it's also much slower
10:36:15 <heat> rain1: Why would you ever map them to a zeroed page?
10:36:23 <sham1> Frankly, optimising checking if you have the right to access something does seem like the kind of thing you'd want to do, considering that you access stuff all the time and doing a quick check for if you can write to, say, /etc/fstab is IMHO quite useful. Of course you can make something more complex and powerful, but would it be worth it
10:36:25 <rain1> so that you get 0 instead of exception
10:36:27 <heat> You either have it mapped or you don't.
10:36:36 <heat> rain1: That's fucking stupid
10:36:43 <rain1> you're mean
10:36:48 <rain1> ill talk to someone else
10:36:59 <heat> well it is stupid
10:37:11 <sham1> Someone calling your idea stupid doesn't make one mean
10:37:19 <sham1> He's not attacking you
10:37:58 <rain1> why is it stupid though doesnt it fix meltdown (at the cost of making programs slower)
10:38:29 <doug16k> is it stupid? if it is not present, it will run through the page fault code, if it is a zeroed page, it won't take a page fault, but the attack won't work either
10:38:47 <heat> it's worse than having it unmapped
10:38:50 <_mjg> adding zeroed pages does not add any value here
10:39:10 <heat> because you use up more address space, need more tables, and you potentially reveal ASLR info
10:39:11 <_mjg> you pay all the current cost of not having the kernel in + extra of putting zeroed pages in pace
10:39:33 <bcos> rain1: After kernel entry, instead of changing pages from "not present" to "present" it'd have to restore the correct addresses from somewhere and then invalidate all of them. Would be more expensive
10:39:43 <doug16k> heat, all of the PML4e slots for the high half can share one zeroed PDPT
10:40:20 <doug16k> except the trampoline
10:40:29 <doug16k> so not technically zeroed
10:40:44 <doug16k> it won't help very much though, but I wouldn't say it is an utterly asinine idea
10:42:02 <heat> still, why would you do that instead of simply unmapping the kernel
10:46:24 <doug16k> you wouldn't. it would only protect against causing page fault exceptions, but the malicious program could do that another way anyway
10:47:15 <rain1> I don't 100% understand this meltdown bug yet but it seems like it works because speculative execution is able to look at kernel memory via unmapped kernel pages
10:47:30 <rain1> so i was wondering - in order to understand the vuln better - what if you actually mapped some data there
10:47:38 <doug16k> what you could do is map in honey pot pages there that mislead the attacker into revealing itself as malicious
10:48:31 <heat> rain1: kernel pages aren't unmapped, you just can't access them if you're not in ring 0
10:48:32 --- part: Guest13020 left #osdev
10:49:12 <heat> they're still there, and that's a big issue because intel screwed things up
10:49:56 --- quit: FreeFull ()
10:50:08 <rain1> so does the way we implement out of order execution inside CPUs need to fundamentally change?
10:50:37 <heat> just do it like AMD and you should be OK
10:51:16 <Kazinsal> Intel should have been doing permissions checking in speculative execution
10:51:27 <Kazinsal> Instead of just assuming CPL==DPL
10:51:31 <rain1> how is AMD doing it different to intel? I think only intel is vulnerable to meltdown but all of them are vulnerable to spectre. is that correct?
10:52:18 --- quit: MindlessDrone (Quit: .)
10:52:49 <heat> https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/
10:52:51 <bslsk05> ​blogs.windows.com: Mitigating speculative execution side-channel attacks in Microsoft Edge and Internet Explorer - Microsoft Edge Dev BlogMicrosoft Edge Dev Blog
10:53:48 <heat> TL;DR: Removed SharedArrayBuffer and reduced the resolution of the high res timer
10:54:02 <Kazinsal> The Spectre thing is interesting because one of the vectors for it is basically return-oriented programming your way into convincing the branch target buffer to mispredict branches into your code
10:54:53 <bcos> I think there's 2 or more high res time sources in javascript, where "performance.now()" is only one
10:54:57 <heat> Oh, looks like firefox did the same
10:55:41 --- join: FreeFull (~freefull@defocus/sausage-lover) joined #osdev
10:57:04 <bcos> "Nerf all timers, and don't support threads or shared memory to prevent software counters" - should work for javascript at least
10:57:41 <heat> If we nerfed every timer source to have a bit more latency wouldn't it protect against these attacks?
10:57:58 <Kazinsal> Looks like it's pretty easy to train performance.now up currently so yeah this might help a bit
10:58:08 <doug16k> javascript has threads (webworkers), but they aren't shared memory, they require heavy IPC overhead to communicate with them
10:58:39 <Kazinsal> That being said I'm seeing average 30 us resolution on it right now in chrome so ???
10:58:40 <bcos> With 2 or more CPUs you can increment a memory location in a loop on one and read it on another (which is why you'd need "no threads, no shared memory between processes")
10:59:04 --- join: zesterer (~zesterer@host86-169-20-84.range86-169.btcentralplus.com) joined #osdev
10:59:05 <cr1901_modern> rain1: What is an "unmapped kernel page"?
10:59:13 <rain1> i dont know
10:59:19 <Kazinsal> First few invocations in a loop have 40-90 us resolution and after that it's about 25 us
10:59:21 <doug16k> cr1901_modern, a page that is not present, at all
11:00:10 <cr1901_modern> How can speculative execution look at a page that isn't present at all? It's not gonna actually _load_ the page in via page fault handler, right?
11:00:16 * bcos is still wondering if setting kernel pages to "uncached" would be enough to stop speculative fetches
11:00:28 <rain1> lets say inside the kernel 0x99329322 points to some part of kernel memory, then in a user process we do *0x99329322 it will throw an exception and fail - but is it true that inside speculative execution it will actually access that value from the kernel?
11:00:47 <rain1> I feel like this must be an oversimplified/wraong understanding of meltdown?
11:01:04 <rain1> but im just trying to make sense of it from the paper
11:01:40 <peterbjo1nx> heh, found some lovely code in one of my students assignments
11:01:49 <cr1901_modern> That's my understanding of it, but I can't imagine it would succeed if the relevant kernel page wasn't in memory at all
11:02:09 <rain1> im not sure paging is very confusing, thats the part of OS dev i gave up at
11:02:14 <heat> Basically, PTI
11:02:20 <rain1> maybe I should continue and then ill understand better
11:02:24 <bcos> rain1: Assume attacker does "movzx rdi, word [kernelAddress]" and then "mov ax,[buffer+edi]". CPU fetches cache line in "buffer" depending on contents of memory at kernelAddress
11:02:26 --- quit: nur (Quit: Leaving)
11:02:26 <peterbjo1nx> portability done wrong: os.system( cls' if os.name = 'nt' else 'clear')
11:02:28 <heat> which is what linux and macos are doing right now
11:02:38 --- join: nur (~hussein@175.141.12.82) joined #osdev
11:03:05 --- quit: ornitorrincos (Quit: ZNC 1.6.5 - http://znc.in)
11:04:02 --- join: ornitorrincos (~ornitorri@163.172.62.96) joined #osdev
11:04:06 --- quit: ornitorrincos (Changing host)
11:04:06 --- join: ornitorrincos (~ornitorri@unaffiliated/ornitorrincos) joined #osdev
11:04:13 <peterbjo1nx> have you guys seen https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equally
11:04:13 <bslsk05> ​media.ccc.de: media.ccc.de - Are all BSDs created equally?
11:04:28 <_mjg> nothing interesting
11:04:41 <geist> yay more FUCKWIT discussions
11:04:42 <_mjg> nobody audits or fuzzes bsd
11:05:03 <geist> speaking of, last night i checked and for sure AMD does not implement PCID
11:05:05 <peterbjo1nx> apparently the BSDs have quite a bit of denial of service bugs
11:05:13 <geist> so the FUCKWIT stuff would definitely be expensive there
11:05:32 <geist> but i haven't completely internalized the PCID based FUCKWIT solution
11:06:08 <geist> peterbjo1nx: yeah the best one was recently when someone discovered that openbsd forgot to disable SMAP in certain paths
11:06:16 <heat> geist: Doesn't AMD have some kind of address space ID as well?
11:06:17 <_mjg> peterbjo1nx: even linux gets something to this very day (found with fuzzers), except it takes more time than on bsds
11:06:19 <geist> was just a half-assed job from the looks of it
11:06:27 <doug16k> geist, I thought AMD enforces the permission check in speculative execution so the workaround is not needed
11:06:30 <geist> heat: doesn't appear to. it has ASID, but it's entirely tied to the SVM stuff
11:06:32 <_mjg> geist: and freebsd does not do smap in the first place
11:06:35 <heat> oh
11:06:56 <sham1> Holy shit, it hasn't even been a day yet the Internet is just... saturated with this Intel stuff
11:06:57 <geist> doug16k: yes and no. for variant 3 yes, but variant 1 and 2 are still there, though admittedly they're less dangerous
11:07:07 <geist> sham1: you shoulda been here yesterday
11:07:15 <sham1> I probably should have
11:07:25 <sham1> I presume it was ever worse
11:07:36 <geist> well, 'worse' or 'great' depending
11:07:37 <geist> i lthink it's all fascinating
11:07:48 <sham1> Of course
11:07:52 <geist> we had a lot of in depth conversations about technical aspects of it, how it applies to operating systems, etc
11:08:07 <geist> really drags folks out of the woodwork. it's why this channel exists
11:08:25 --- join: wcstok (~Me@c-71-197-192-147.hsd1.wa.comcast.net) joined #osdev
11:08:27 <sham1> And that's commendable
11:08:44 <geist> and it's fresh on my mind because of the zircon project
11:08:54 <peterbjo1nx> zircon?
11:08:56 <heat> the best solution is to watch what windows does and do it like they do
11:09:08 <heat> peterbjo1nx: zircon is magenta's new name
11:09:08 <geist> and sure enough, we gotta implement it too on both x86 and arm, so i'm going to have to understand the ins and outs of this on both architectures
11:09:16 <peterbjo1nx> inb4 m$ patents their fix
11:09:19 <Brnocrist> what windows used to patch spctre? not retpoline?
11:09:27 <geist> yah i got tired of typing fuchsia/magenta/zircon
11:09:30 <geist> so folks gotta keep up
11:09:49 <bcos> By the time I remember "zircon" they'll probably change the name again.. :-)
11:09:59 <geist> peterbjo1nx: if they do, please do not talk abuot it here. patents are an area that we are very strict about on this channel
11:10:02 <sham1> "Google's Microkernel clusterfuck"
11:10:09 <geist> hah
11:10:17 <sham1> Or GMC for short
11:10:18 <geist> nah, we are not changing it again. ever
11:10:27 <geist> it was a big undertaking, and we have a lot more code on top now
11:10:31 <doug16k> google loves breaking changes. why would project names be excluded :D
11:10:42 <peterbjo1nx> geist, eh what?
11:10:52 --- quit: nzoueidi (Ping timeout: 265 seconds)
11:11:12 <geist> it was mostly why we changed it, because we needed to settle on final names forevermore
11:11:15 <geist> as stuff solidified
11:11:30 <bcos> It's a pity google didn't use something unique - calling it "oaibaiob" would make it much easier to find with bing
11:11:35 <geist> without collisions with other projects and trademark issues, etc
11:11:51 --- join: unixpickle (~alex@2601:645:8103:60b6:a55b:1e3c:9dd3:30d9) joined #osdev
11:11:55 <geist> yah, when you're as big as we are, you gotta run everything through lawyercats and they're not that funny
11:12:02 <sham1> Bing? You must jest! It's all about DuckDuckGo
11:12:09 <heat> Brnocrist: See above, basically they're going to use a new msr and fallback to a trampoline that fucks with the BTB
11:12:11 <bcos> :-)
11:12:13 <geist> peterbjo1nx: oh just saying we dont talk about patents at all here
11:12:26 <geist> since a lot of us work in industry and plausible deniability is a real thing
11:12:32 <doug16k> I asked my computer for a unique name and it suggested 6b91ea95-c525-42a0-aabe-7705f879838f
11:12:44 <bcos> We don't talk about the contents of patents; but feel free to complain about how much the patent system sucks..
11:12:47 <glauxosdever> http://forum.osdev.org/viewtopic.php?p=281554#p281554 <- That ~ again...
11:12:48 <bslsk05> ​forum.osdev.org: OSDev.org • View topic - CPU bug makes virtually all chips vulnerable
11:12:49 <geist> yah
11:13:03 <geist> peterbjo1nx: not picking on you,just using it as an opportunity to remind everyone
11:13:36 <peterbjo1nx> is there any place i can find the policy, i dont really get what you're getting at. No politics discussions about sw patents?
11:13:44 <geist> that's about it
11:13:44 <sham1> Oh, $HOME having one of their weird views on things again, eh?
11:13:53 <peterbjo1nx> ah, ok.
11:14:05 <glauxosdever> Yeah..
11:14:06 <geist> peterbjo1nx: no, dont talk about contents of any patent, or the presence of a patent that may exist on a particular technology
11:14:18 <geist> you can bitch about patents, but no specifics
11:14:28 <bcos> peterbjo1nx: If you don't know about a patent then you can say "oops, didn't know". If lawyers find IRC logs to prove you did know then...
11:14:28 --- join: jakogut (~jakogut_@162.251.69.147) joined #osdev
11:14:37 <peterbjo1nx> ok. I was just mentioning that it would be really bad if microsoft decided to patent something in the future
11:14:56 <geist> yeah, like i said i was just using it as an opportunity to remind folks not to go any farther than that
11:14:59 <Kazinsal> The good thing is I think those days are gone
11:15:13 <peterbjo1nx> ok, so mostly dont break people's plausible deniability
11:15:18 <geist> right on
11:15:19 <Kazinsal> They seem more interested in patenting things that everyone realizes is a terrible idea, like a phone composed of two giant touchscreens
11:16:06 * geist waves at future lawyers scanning these logs for 'geist' and 'patent'
11:16:09 <geist> nothing to see here!
11:16:31 <bcos> For this specific case; I think people are too busy trying to fix the nightmare to spend time dragging lawyers back from vacations..
11:16:47 <glauxosdever> geist: Did you know about that patent?
11:16:48 <glauxosdever> :p
11:16:57 <geist> nah i'm more worried about 5 years from now
11:16:57 <geist> or whatnot
11:16:58 <sham1> Oh yeah, that
11:17:11 <geist> glauxosdever: i do not!
11:17:30 <glauxosdever> Well, now you do.
11:17:30 <bcos> Does everyone know about all of my "scanning IRC logs" patents? :-)
11:17:39 <geist> doubleplus so when fuchsia turns into a complete juggernaut and the lawyers come out of the woodwork
11:17:48 <geist> and being that i'm the primary kernel dev, etc
11:18:48 <Brnocrist> heat: oh, I didnt read :)
11:19:36 --- join: MindlessDrone (~MindlessD@unaffiliated/mindlessdrone) joined #osdev
11:21:40 <zesterer> Hahaha... These slides from 2002 talking about branch prediction: http://cseweb.ucsd.edu/classes/wi02/cse240/carmean.pdf
11:22:25 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:25:47 <zesterer> Meltdown exploit here if anyone's interested: https://pastebin.com/raw/fDHrAEuZ
11:25:48 <bslsk05> ​pastebin.com <no title>
11:27:21 <ohnx> zesterer: code has been released?
11:27:27 <rain1> is this file illegal?
11:27:29 <ohnx> thought it was supposed to wait until next week
11:27:38 <zesterer> I have absolutely no idea, but apparently it works
11:28:01 <peterbjo1nx> exploits aren't illegal afaik
11:28:04 <zesterer> I'm gonna test in later on when I've finished with work
11:28:08 <zesterer> *it
11:28:18 <peterbjo1nx> but i am not a lawyet etc etc etc
11:28:24 --- join: brkt (~quassel@177.69.179.225) joined #osdev
11:28:56 <sham1> YANAL?
11:29:11 <sham1> Anyways
11:32:16 --- quit: dennis95 (Quit: Leaving)
11:32:30 --- join: navidr (uid112413@gateway/web/irccloud.com/x-idkhjcvugkiumgtq) joined #osdev
11:36:10 <peterbjo1nx> are there actually countries that outlaw posession of exploits? i know some have outlawed tools like lockpicks so wouldn't suprise me
11:52:46 <Brnocrist> heat: do you know on which version of cpu this msr can be used?
11:53:44 <Kazinsal> https://twitter.com/KateLibc/status/948979943999815680
11:53:45 <bslsk05> ​twitter: <KateLibc> If your Mac has a PowerPC 604 (not 604e) or earlier, it doesn't do speculative execution. ␤ ␤ Time to switch back to my low-spec Power Mac 8500.
11:53:51 <heat> Brnocrist: For now, none
11:54:01 <Brnocrist> so this patch is not usable right now?
11:54:14 <heat> yes, it's still under embargo
11:54:37 <heat> they're probably waiting for intel to issue a microcode update or something
11:55:53 <Brnocrist> yeah
11:57:14 --- join: fujisan (uid4207@gateway/web/irccloud.com/x-mvcigpfpxtqprngx) joined #osdev
11:59:17 --- quit: peterbjornx (Disconnected by services)
11:59:27 --- nick: peterbjo1nx -> peterbjornx
11:59:43 --- quit: bm371613 (Quit: Konversation terminated!)
12:00:31 --- join: peterbjornx_ (~peterbjor@50709D65.static.ziggozakelijk.nl) joined #osdev
12:03:21 <zesterer> peterbjornx: Well possession of DRM primes is illegal in most western nations
12:03:35 <zesterer> peterbjornx: Which is arguably an exploit
12:03:37 <peterbjornx> yeah, the DMCA is a bitch
12:03:53 <peterbjornx> i wouldnt consider keys to be an exploit, just corporate secrets
12:05:39 <zesterer> Fair enough
12:07:33 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
12:07:50 --- quit: Belxjander (Ping timeout: 240 seconds)
12:08:54 --- quit: freakazoid0223_ (Ping timeout: 248 seconds)
12:09:32 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
12:12:06 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
12:22:50 --- quit: sprocklem (Ping timeout: 240 seconds)
12:24:23 --- quit: Belxjander (Ping timeout: 260 seconds)
12:31:34 --- join: teej (uid154177@gateway/web/irccloud.com/x-klcnjbzhksegylqq) joined #osdev
12:32:54 --- quit: oaken-source (Ping timeout: 248 seconds)
12:36:59 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
12:39:18 --- quit: daniele_athome (Ping timeout: 248 seconds)
12:39:48 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
12:41:02 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
12:46:24 --- quit: Belxjander (Ping timeout: 256 seconds)
12:47:35 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
12:55:20 --- quit: caen23 (Ping timeout: 248 seconds)
13:01:00 --- quit: roxfan (Remote host closed the connection)
13:03:07 --- quit: brkt (Remote host closed the connection)
13:06:28 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
13:07:49 <fnodeuser> https://www.youtube.com/watch?v=TEAO7jhxxwk
13:07:50 <bslsk05> ​'2017 Thinkpad vs.1997 Thinkpad – 25 Anniversary Edition Review' by Linus Tech Tips (00:09:30)
13:09:41 <heat> linus tech tips lol no ty
13:10:57 <fnodeuser> :P
13:15:04 <Kazinsal> Dude's paid to be an idiot but I like his teardowns
13:15:13 <Kazinsal> Like that ASUS ROG laptop that literally has a desktop Ryzen socketed in it
13:20:20 <fnodeuser> he's a good computer dude
13:23:42 <froggey> linux patch with details on the speculation control msrs: https://lkml.org/lkml/2018/1/4/622
13:23:43 <bslsk05> ​lkml.org: LKML: Tim Chen: [PATCH 1/7] x86/feature: Detect the x86 feature to control Speculation
13:25:27 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
13:29:40 --- nick: iIIuminati -> Ajarm
13:31:35 --- nick: Ajarm -> lightwalker
13:32:24 <radens> geist: did you see this new MSR Intel flipped on in microcode to control branch prediction? I bet it will really help fuschia avoid this awful perf degredation: https://patchwork.kernel.org/patch/10145335/
13:32:26 <bslsk05> ​patchwork.kernel.org: [1/7] x86/feature: Detect the x86 feature to control Speculation - Patchwork
13:33:08 --- quit: Zerith (Ping timeout: 268 seconds)
13:34:41 --- join: Asu` (~sdelang@80.12.63.228) joined #osdev
13:34:46 --- quit: Asu (Ping timeout: 248 seconds)
13:37:54 <radens> I take that back, it looks like it only applies to variant 2 of the attack.
13:41:40 --- join: KidBeta (~textual@220-244-156-86.tpgi.com.au) joined #osdev
13:50:04 --- quit: voidah (Remote host closed the connection)
13:50:08 --- quit: quc (Ping timeout: 260 seconds)
13:56:54 --- quit: Retr0id (Remote host closed the connection)
13:57:19 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
13:59:58 --- join: smeso (~smeso@unaffiliated/smeso) joined #osdev
14:06:28 --- quit: NotSecwitter (Ping timeout: 260 seconds)
14:07:22 --- join: xerpi (~xerpi@200.red-88-23-236.staticip.rima-tde.net) joined #osdev
14:10:18 --- quit: inode (Quit: )
14:11:49 --- join: grange_c (uid262389@gateway/web/irccloud.com/x-jcyqzkvrtlyzzcof) joined #osdev
14:12:53 --- quit: KidBeta (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
14:19:20 --- quit: raphaelsc (Ping timeout: 240 seconds)
14:20:47 --- quit: GautamS (Read error: Connection reset by peer)
14:23:33 --- join: GautamS (~GautamS@59.182.250.169) joined #osdev
14:25:21 <sortie> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u0.s ← Best first comment ever: “/ u0 -- unix”
14:25:24 <bslsk05> ​minnie.tuhs.org <no title>
14:27:20 <Kazinsal> "What's in that file?" "Oh, you know, unix."
14:27:42 <heat> good ol' times when cpus didn't speculate
14:28:51 --- join: GautamS_ (~GautamS@59.182.250.190) joined #osdev
14:29:12 <Kazinsal> I'm disappointed u1.s doesn't start with "/ u1 -- more unix"
14:29:38 --- join: raphaelsc (~utroz@179.186.168.22.dynamic.adsl.gvt.net.br) joined #osdev
14:29:50 <Kazinsal> Are these original circa 1969 comments or added later?
14:30:48 --- quit: user10032 (Remote host closed the connection)
14:30:50 --- join: Arcaelyx_ (~Arcaelyx@2601:646:c200:27a1:7c17:5880:9e2f:b126) joined #osdev
14:31:03 --- quit: navidr (Quit: Connection closed for inactivity)
14:31:39 <Kazinsal> Oh wow, looks like they're originals
14:31:40 <Kazinsal> Neat
14:32:20 --- quit: GautamS (Ping timeout: 268 seconds)
14:32:21 --- quit: Arcaelyx (Ping timeout: 276 seconds)
14:32:40 --- quit: glauxosdever (Quit: leaving)
14:33:46 <heat> I prefer https://github.com/dspinellis/unix-history-repo
14:33:46 <bslsk05> ​dspinellis/unix-history-repo - Continuous Unix commit history from 1970 until today (189 forks/2549 watchers)
14:34:10 <sortie> Kazinsal: Yeah originals
14:34:37 <heat> even has research unix
14:35:55 <Kazinsal> PDP-11 assembly is nice
14:36:19 <Kazinsal> The same site has a copy of the PDP-7 Unix kernel and it's so different
14:39:20 --- quit: sprocklem (Ping timeout: 240 seconds)
14:41:02 --- join: navidr (uid112413@gateway/web/irccloud.com/x-bfvzaqhynfmefmau) joined #osdev
14:42:41 --- quit: GautamS_ (Read error: Connection reset by peer)
14:44:32 --- join: GautamS_ (~GautamS@59.182.251.1) joined #osdev
14:49:20 --- quit: GautamS_ (Read error: Connection reset by peer)
14:51:03 --- join: GautamS_ (~GautamS@59.182.251.25) joined #osdev
14:54:03 --- quit: GautamS_ (Remote host closed the connection)
15:03:49 --- join: Darmor (~Tom@198-91-187-5.cpe.distributel.net) joined #osdev
15:04:28 --- quit: Asu` (Quit: Konversation terminated!)
15:05:30 --- join: KidBeta (~textual@220-244-156-86.tpgi.com.au) joined #osdev
15:07:36 --- join: azonenberg_work (~azonenber@216.243.3.82) joined #osdev
15:12:24 --- quit: wgrant (Ping timeout: 248 seconds)
15:13:28 --- quit: azonenberg_work (Ping timeout: 248 seconds)
15:14:28 --- join: wgrant (~wgrant@ubuntu/member/wgrant) joined #osdev
15:18:35 --- quit: xerpi (Quit: Leaving)
15:19:20 --- quit: grumble (Quit: We all eat lies when our hearts are hungry)
15:23:37 --- quit: sortie (Quit: Leaving)
15:25:17 --- join: grumble (~grumble@freenode/staff/grumble) joined #osdev
15:27:06 --- quit: Zerith|3 (Ping timeout: 272 seconds)
15:27:33 --- join: azonenberg_work (~azonenber@12.130.118.25) joined #osdev
15:33:02 --- quit: gdh (Quit: Leaving)
15:38:31 --- quit: KidBeta (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
15:51:18 --- quit: azonenberg_work (Remote host closed the connection)
15:52:47 --- join: azonenberg_work (~azonenber@12.130.118.25) joined #osdev
15:53:15 --- quit: azonenberg_work (Remote host closed the connection)
15:56:00 --- join: Extern (~Extern@184.20.228.70) joined #osdev
15:57:01 --- part: Extern left #osdev
15:58:26 --- quit: ekr (Read error: Connection reset by peer)
15:58:44 --- join: ekr (~ekr@188.24.96.215) joined #osdev
15:58:44 --- quit: ekr (Changing host)
15:58:44 --- join: ekr (~ekr@unaffiliated/ekr) joined #osdev
16:03:51 --- join: azonenberg_work (~azonenber@12.130.118.25) joined #osdev
16:04:47 --- quit: azonenberg_work (Remote host closed the connection)
16:07:18 --- quit: uvgroovy (Ping timeout: 248 seconds)
16:16:34 --- join: azonenberg_work (~azonenber@12.130.118.25) joined #osdev
16:16:39 --- quit: azonenberg_work (Remote host closed the connection)
16:17:33 --- quit: m_t (Quit: Leaving)
16:18:50 --- join: azonenberg_work (~azonenber@12.130.118.25) joined #osdev
16:18:55 --- quit: azonenberg_work (Remote host closed the connection)
16:21:10 --- join: godel (~gonzalo@96-251-231-201.fibertel.com.ar) joined #osdev
16:22:17 --- join: gdh (~gdh@2605:a601:639:2c00:884a:2536:4f7c:82cf) joined #osdev
16:22:20 --- quit: awang_ (Ping timeout: 240 seconds)
16:24:54 --- quit: Belxjander (Ping timeout: 248 seconds)
16:25:50 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
16:30:51 --- quit: vaibhav (Quit: Leaving)
16:32:39 --- quit: xenos1984 (Quit: Leaving.)
16:32:54 --- quit: empy (Ping timeout: 248 seconds)
16:36:17 --- join: awang_ (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
16:54:12 --- quit: John___ (Read error: Connection reset by peer)
16:57:57 --- quit: gdh (Quit: Leaving)
16:59:24 --- join: orion (~orion@unaffiliated/orion) joined #osdev
17:00:38 --- quit: dhoelzer (Ping timeout: 248 seconds)
17:01:26 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
17:02:11 <orion> Hi. I am trying to better understand how the Meltdown and Spectre attacks work. In particular, I'm trying to understand how L3 side channel attacks work.
17:03:04 <orion> After reading https://eprint.iacr.org/2013/448.pdf I have specific questions.
17:04:39 --- quit: awang_ (Ping timeout: 268 seconds)
17:04:57 <orion> The paper describes a technique for measuring the time it takes to access memory and inferring what is happening (multiply, reduce, etc) based on that information.
17:04:59 --- quit: fujisan (Quit: Connection closed for inactivity)
17:06:15 <orion> They describe a function called "probe" (figure 4) which is able to perform the measurement. It takes a single argument, the memory address to probe.
17:06:46 <orion> What I'd like to understand is, *how* do they determine what memory address to probe?
17:07:40 --- join: mmu_man (~revol@vaf26-2-82-244-111-82.fbx.proxad.net) joined #osdev
17:08:25 <orion> The way I understand it, the memory of one process is isolated from another process through virtual page tables.
17:12:58 <Mutabah> One of those (I think it's Meltdown?) work on kernel addresses (addresses that user code can't actually access, but do exist within their address space)
17:13:26 <variable> Meltdown does
17:13:31 <orion> Right, I think I'm referring to Spectre.
17:13:34 <variable> specrete uses branch prediction
17:13:45 <mmu_man> oh, why did I guess the subject here :)
17:13:46 <mmu_man> plop
17:14:00 <variable> mmu_man: give it 6 months
17:14:01 <orion> Specifically, the recovery phase, which is via the flush+reload techique I linked to above.
17:14:07 <mmu_man> as a distraction, anyone knows about stack alignment constraints on x86?
17:14:21 <mmu_man> variable: I didn't finish reading the papers yet, but it sounds promising
17:14:45 <mmu_man> someone suggested we all change job to raising goats in ardèche
17:14:54 <variable> mmu_man: for x86 for real? IIRC none; gcc does something stupid though and everyone else was forced to copy
17:15:16 <mmu_man> variable: well, for SysV ABI.
17:15:24 <mmu_man> I'm running Haiku on an athlon xp
17:15:35 <variable> "I'm running Haiku...."
17:15:38 <variable> that's a first
17:15:56 <mmu_man> and Qt crashes with an invalid opcode (movq %xmm0,offset(bp))
17:16:07 <mmu_man> why, nobody from Haiku ever show up here?
17:16:14 <mmu_man> I know we have the best but still :p
17:16:17 <variable> mmu_man: twas a joke
17:16:29 <variable> but actually a first for me
17:17:17 <orion> How is it that the authors know which memory address to probe? How is it selected?
17:17:33 <mmu_man> variable: eh :p
17:17:58 <Mutabah> mmu_man: 8 bytes iirc (two words)
17:18:00 <mmu_man> orion: why would you need to choose when you can dump the whole address space?
17:18:07 <Mutabah> Generally you align your stack to two registers
17:18:33 <variable> Mutabah: why two registers?
17:19:05 <mmu_man> Mutabah: I've read 16 but maybe that was only 64bit
17:19:13 <variable> mmu_man: that's the gccism
17:19:15 <orion> mmu_man: Because I am trying to understand the L3 flush+reload side channel attack.
17:19:31 <mmu_man> ok, but then, which is it which shall be aligned...
17:20:12 <Mutabah> variable: Various reasons, partially becuase it allows a double-word value to be stored aligned (e.g. a 64-bit value on x86)
17:20:15 <mmu_man> http://www.mindfruit.co.uk/2012/02/stack-alignment.html the forumlation is obscure
17:20:16 <bslsk05> ​www.mindfruit.co.uk: Some Assembly Required*: Stack Alignment
17:20:32 <variable> mmu_man: http://www.sco.com/developers/devspecs/abi386-4.pdf might help you?
17:20:34 --- quit: jakogut (Remote host closed the connection)
17:20:37 <Mutabah> mmu_man: Yeah, x86-64 requires 16-byte alignment
17:20:57 <mmu_man> yeah well the problem is understanding where it must be aligned
17:21:00 <variable> mmu_man: ". Although the architecture does not require any alignment of the stack, software convention and the operating system requires that the stack be aligned on a word boundary."
17:21:08 <mmu_man> I have all frames as 0x...8
17:21:13 <variable> see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842
17:21:16 <bslsk05> ​gcc.gnu.org: 47842 – gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment
17:21:33 <variable> and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
17:21:37 <bslsk05> ​gcc.gnu.org: 38496 – Gcc misaligns arrays when stack is forced follow the x8632 ABI
17:21:49 <doug16k> you can tell gcc what alignment to use on the command line
17:22:00 <variable> doug16k: IIRC it didn't actually work in the 4.3 days
17:22:07 <variable> you could tell it, but it would ignore it
17:22:21 <mmu_man> yeah, and building Qt with -mstackrealign seems to fix it
17:22:22 <variable> I'm also really tired right now, so am mostly just posting links
17:22:29 <mmu_man> although it looks weird
17:22:36 <mmu_man> yeah it's 2am
17:22:43 <variable> its 5:30pm
17:22:46 <variable> :-)
17:23:00 <doug16k> no it isn't, it's 8:22pm :P
17:23:29 <doug16k> I'm the only real person. you're all simulated people
17:24:05 <variable> doug16k: everyone else is a robot but you
17:24:39 <variable> doug16k: https://www.reddit.com/r/AskReddit/comments/348vlx/what_bot_accounts_on_reddit_should_people_know/
17:24:43 <bslsk05> ​www.reddit.com: What bot accounts on reddit should people know about? : AskReddit
17:24:55 <variable> also, this is a 2 feet fo snow https://i.imgur.com/qWbqsPE.jpg
17:26:37 <mmu_man> anyway, what I don't get is which should be aligned, ebp or esp before entry
17:27:01 <mmu_man> like, __builtin_frame_address(0) % N == 0 ? or 8 ?
17:27:45 <mmu_man> on linux 64bit I get 0x...0
17:27:51 <mmu_man> but on Haiku I get an 8
17:27:57 <mmu_man> (but that's on 32bit)
17:29:35 --- quit: alphawarr1or (Quit: Connection closed for inactivity)
17:35:04 --- quit: variable (Quit: /dev/null is full)
17:36:33 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
17:37:58 --- join: empy (~l@c-24-56-245-159.customer.broadstripe.net) joined #osdev
17:37:58 --- quit: empy (Changing host)
17:37:58 --- join: empy (~l@unaffiliated/vlrvc2vy) joined #osdev
17:39:04 <mmu_man> hmm i386 abi doesn't really help
17:39:38 --- nick: clickjack -> immersive
17:40:42 <orion> Would I be correct in saying that an OS's dynamic linker (ld-linux, for example), is responsible mainly for mmap()ing shared libraries at very specific memory addresses within a process's virtual memory?
17:40:44 <mmu_man> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842#c3
17:40:47 <bslsk05> ​gcc.gnu.org: 47842 – gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment
17:40:50 <mmu_man> yeah that's exactly what happens
17:41:52 <orion> How does the linker determine the destination memory address at which a library is to be mapped?
17:41:58 <orion> Where in the ELF is it?
17:42:14 --- quit: Shamar (Quit: leaving)
17:43:14 --- join: awang_ (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
17:43:30 <geist> orion: generally they dont. the linker gets to decide
17:43:54 <geist> usually libraries are linked to appear to run at address 0, and then there are relocation entries in case you want to load it somewhere else
17:44:21 <geist> you *could* go through and prelink all of your libraries to run at a globally unique address, and some distros used to do that back in the day before ASLR
17:44:34 --- quit: vmlinuz (Ping timeout: 250 seconds)
17:44:44 <geist> in which case you simply pre-relocate the binary to have a starting offset at the final location, though you can still go through the REL/RELA entries to move it somewhere else
17:44:50 <mmu_man> either they are built with PIC or the linker patches all the pointers mentionned in the relocation list inside the library with the load offset
17:45:59 <orion> Before linking takes place, what memory address do the CALL instructions point to when making a call to, say, my_library_func()?
17:46:11 <orion> dynamic linking*
17:46:13 <geist> depends
17:46:22 <geist> probably 0
17:46:40 <geist> because the REL entry will say 'patch at offset X in the binary (where the call instruction is) to put the address of function Y'
17:46:57 <geist> but it doesn't always work that way, because REL/RELA entries are more complicated than that, but that's *basically* what happens
17:48:00 <geist> that's the key to the whole thing, the REL/RELA table in the ELF binary basically has a little table of opcode + data that tells the loader how to patch the binary to relocate it and resolve external symbols
17:48:13 <geist> without really knowing what it's doing, its just replacing values at certain memory addresses with others
17:48:24 <mmu_man> or adding to existing offsets
17:48:59 <geist> exactly. sometimes it takes a value and adds to it, sometimes it replaces it entirely, etc
17:49:04 <mmu_man> and since there are so many addressing modes (soetimes really funky) there are many relocation types
17:49:05 <geist> that's what the different opcodes are for
17:49:25 <mmu_man> sometimes it's an offset encoded inside the instruction itself
17:49:26 <geist> but the gist is it effectively fudges up what was there to now be proper
17:49:44 <geist> and the loader doesn't really need to care what for, it just follows the instructions
17:50:05 <mmu_man> oh, gee, variable tricked me into downloading something from sco.com
17:50:05 <orion> Ok, so if I understand correctly, the linker consults a "relocation table" present in the executable. The table consists of human readableish symbols paired with code segment memory locations which need to be patched.
17:50:08 <mmu_man> now my brain is tainted
17:50:26 <geist> orion: basically, yes
17:50:30 <orion> Gotcha.
17:50:39 <geist> the symbols are references into the symbol table, but that's basically a packed list of strings
17:50:53 <geist> it's up to the linker to resolve symbols against other libraries it has loaded, etc
17:51:04 <geist> and there's a whole search order thing going on when there are multiple libraries involved
17:51:21 <orion> 0000000000600a38 R_X86_64_JUMP_SLOT printf@FBSD_1.0 <-- like this
17:52:33 <mmu_man> yes, although the R_* names are just symbols, the table actually contains an int
17:53:13 <mmu_man> this one means patch the jmp opcode at $address to jump to printf@...
17:53:43 <mmu_man> oh dear, 3am
17:54:01 <geist> orion: yeah it doesn't literally look like that, that's the human readable version of it
17:54:20 <geist> it's really something like opcode that represents R_* and then an index into the string table that resolves to printf....
17:54:27 <geist> it's a fairly compact table
17:55:45 <orion> Sure.
17:55:59 <orion> Ok, so maybe I am starting to understand how this side channel attack works.
17:56:43 <mmu_man> what's the relation to relocation?
17:56:51 <mmu_man> I really need to finish reading those papers :)
17:57:04 <orion> mmu_man: Probably nothing.
17:58:37 <mmu_man> hmm, I thought hachoir could show the relocation table but it only shows the main header :-(
17:59:04 <orion> Let's say that I dynamically link against libssl.so. The file is read from disk once initially and copied to main memory. Every subsequent mmap of libssl.so happens virtually via page tables.
17:59:39 <mmu_man> yes
17:59:47 <mmu_man> for the read-only part
17:59:59 <mmu_man> the r/w one is probably mapped copy-on-write
18:00:21 <geist> yep
18:00:48 <mmu_man> that is, the page table entries point to the same page, but a flag prevents write and tells the kernel to replace it with a clone that can be changed
18:01:00 <orion> Let's say that there is a high level function multiply() in libssl.so. By evicting the L1, L2, and L3 caches, I can ensure that that code needs to be read from main memory when it is called.
18:01:03 <mmu_man> so each copy can have different variables
18:01:23 <geist> mmu_man should know this. he literally has MMU in his name
18:01:32 <mmu_man> :p
18:01:54 * mmu_man wonders why they just don't make cache flush opcodes fixed-time
18:02:01 <mmu_man> or add a random number or cycles
18:02:07 <mmu_man> could be done with a microcode patch
18:02:18 <geist> yeah but it's easy enough to just flush them via reading a bunch of other crap
18:02:23 <mmu_man> as essentially it's by measuring flush time that it gets the data
18:02:35 <geist> ah. i see
18:02:58 <mmu_man> it the cycle count doesn't reflect the actual flush anymore...
18:03:07 <mmu_man> but there's probably more to it
18:03:14 <geist> i think there is
18:03:18 <mmu_man> the paper mentions many possible ways with the cache
18:03:27 <orion> So in theory (and now in practice), I can repeatedly flush the cache and immediately load the multiply() instruction, timing how long it takes.
18:03:52 <orion> By doing this over and over, I can tell how many times the multiply() instruction gets used.
18:04:00 <geist> right
18:04:09 <mmu_man> or maybe raise a protection exception when the flush happens on address on different rings
18:04:38 <orion> And if I apply this technique with reduce() and other cryptographic primitives simultaneously, I can view which operations are taking place.
18:05:05 <orion> And if I can view which mathematical operations are taking place, I can infer what the secret exponent is.
18:05:19 <orion> Does all this make sense?
18:05:23 <mmu_man> that's why crypto implements should never use branches or lookups
18:05:35 * mmu_man watched a 34C3 talk about that
18:05:36 <mmu_man> :D
18:05:43 <mmu_man> because it's easy to measure
18:05:47 <orion> Ok, so I finally understand now.
18:07:36 <mmu_man> hmm this page uses radare also with relocations http://michalmalik.github.io/elf-dynamic-segment-struggles
18:07:36 <bslsk05> ​michalmalik.github.io: ELF: dynamic struggles - Michal Malik’s blog
18:07:45 --- quit: tacco\unfoog ()
18:07:45 <mmu_man> different presentation
18:15:24 --- join: dbittman (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
18:17:12 <raphaelsc> spent all my day working on this: https://github.com/raphaelsc/Am-I-affected-by-Meltdown
18:17:13 <bslsk05> ​raphaelsc/Am-I-affected-by-Meltdown - Checks whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN. (0 forks/1 watchers)
18:17:37 <raphaelsc> geist: ^
18:17:45 <geist> cute
18:18:37 <raphaelsc> how it works: "It works by using /proc/kallsyms to find system call table and checking whether the address of a system call found by exploiting MELTDOWN match the respective one in /proc/kallsyms."
18:19:23 <geist> note that many distros (thsi one i'm on included) dont let user processes read addresses in /proc/kallsyms
18:19:26 <geist> they're all zero here
18:19:46 --- quit: dmj` ()
18:21:09 <Mutabah> can you sidt in userland? :D
18:21:36 <raphaelsc> geist: i assume that in such scenario the attacker is left with no choice but to dump the entire kernel memory, right?
18:22:08 <raphaelsc> given that he has no clue of where anything is stored.
18:24:52 <mmu_man> ohhhhkay
18:24:59 <mmu_man> I should really sleep but I think I nailed it down
18:25:28 --- quit: daniele_athome (Ping timeout: 260 seconds)
18:26:12 <clever> raphaelsc: 2018-01-03 21:36:12< gchristensen> like ... --- BEGIN PRIVATE KEY ---
18:26:49 <mmu_man> geist: arch_thread_enter_userspace calls arch_randomize_stack_pointer which does return a 16byte aligned value, *but* then it pushes the return address to commpage_exit_thread
18:27:06 <geist> yeah that's common
18:27:10 <mmu_man> so the stack is aligned but not the calling frame
18:27:17 <mmu_man> so the next frame isn't either
18:27:25 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
18:27:28 <geist> that's correct. x86-64 says the stack is aligned up until the call is done
18:27:39 <geist> so basically at the start of any function the stack is supposed to be precisely 8 byte misaligned
18:28:22 <mmu_man> hmm yeah but somehow gcc assumes the frame itself is aligned, not the calling sp
18:29:01 <clever> pushing a frame pointer onto the stack may re-align it?
18:29:09 <geist> clever: correct
18:29:22 <mmu_man> the callee does it
18:29:29 <geist> mmu_man: gcc assumes it's precisely 8 byte misaligned and operates accordingly
18:29:41 <geist> if the caller messes it up then it gets fouled up from then on out
18:30:07 <mmu_man> well something is really wrong somewhere
18:30:45 <mmu_man> cause on my athlon xp the frames are correct, but it emits a movq %xmm0, -0x10(ebp), and ebp is ...8
18:31:18 <mmu_man> so invalid opcode due to insufficient alignment
18:31:37 <geist> usually it's some sort of assembly routine that fouls it up
18:33:32 <mmu_man> we fixed the crt stuff and the qt package hasn't been rebuilt yet, but the fix only adds 4, not 8
18:33:40 <mmu_man> so it seems to be something else
18:34:13 <mmu_man> when I compile qt or webkit with -mstackrealign it works
18:34:46 <mmu_man> hmm could it be we don't declare the ABI correctly in the haiku support in gcc and it things it's 32byte aligned or something?
18:34:53 <orion> https://www.youtube.com/watch?v=RbHbFkh6eeE <-- How does this work? Specifically, let's assume you can dump kernel memory. What address would you monitor?
18:34:54 <bslsk05> ​'Meltdown demo - Spying on passwords' by Michael Schwarz (00:00:14)
18:35:57 <mmu_man> orion: I think for the demo the address is hardcoded
18:36:04 <mmu_man> the demo program is built on purpose
18:36:48 <mmu_man> for a real exploit you'd search for signatures in memory, like firefox, and check for strings
18:36:55 <mmu_man> anyway
18:36:56 <mmu_man> zz
18:37:29 <geist> there was some talk about using the BTB to determine function boundaries so you could sniff out specific versions of the kernel you're running
18:42:55 --- quit: heat (Remote host closed the connection)
18:43:25 --- join: uvgroovy (~uvgroovy@c-65-96-163-219.hsd1.ma.comcast.net) joined #osdev
18:44:08 --- quit: uvgroovy (Client Quit)
18:49:27 --- join: gdh (~gdh@2605:a601:639:2c00:3144:2b9e:8ff9:23a6) joined #osdev
18:52:05 <orion> Why do modern OSs map the entire kernel in to the user address space?
18:52:19 <geist> efficiency
18:52:25 <geist> and only on some architectures, like x86
18:53:18 <mmu_man> Linux did it on 32bit
18:53:29 <mmu_man> then stopped because, well 4GB doesn't fit insite 2GB
18:53:37 <mmu_man> then they did it again on 64bit
18:53:42 <Mutabah> kernel, not physical address space
18:53:49 <mmu_man> ah
18:53:50 <geist> most OSes have been doing it on x86 for while
18:54:01 <mmu_man> I was thinking about physical RAM
18:54:11 --- mode: Mutabah set -o Mutabah
18:54:12 <geist> really on most architectures as well. some of them (like POWER/PPC) dont mind having the kernel as a separate address space
18:54:24 <geist> and so many PPC native oses did the switch
18:54:25 <mmu_man> yeah, precisely to avoid having to flush TLBs and cashes on ctx switch and other things
18:54:38 <geist> it's one of the reasons that OSX 32bit when it was first released, actually did this a long time ago
18:54:45 <geist> it had just been freshly ported from PPC
18:55:05 <mmu_man> yeah, x86 doesn't really have a concept of separate address space
18:55:10 <geist> right
18:55:18 <mmu_man> rather a single virtual space with different priviledges on pages
18:55:26 <mmu_man> so it was the simplest way to do it
18:55:28 <geist> most architectures that came later added a notion of an address space id, and that generally mitigates the expense of switching
18:55:55 <geist> then secondarily there's a slight advantage to having user space mapped when the kernel is there, because it's easier to copyin/copyout of the kernel for IO
18:56:21 <nsh> hi, so is there a simple way to map form a process's virtual memory mappings to physical addresses as represented via the kernel's mapping of physical memory?
18:56:27 <nsh> in linux
18:56:31 <geist> also keep in mind original x86-32 had the segmentation that you could overlay on top of paging, and that sort of mitigated a bunch of this stuff
18:56:44 <geist> since the cpu could do the permission check prior to getting to paging via the segmentation mechanism
18:56:57 <geist> but since that's gone on x86-64 it has to rely on paging and thus TLB to do it, which can be relatively expensive
18:57:16 <geist> which is probably why intel skipped doing the check synchronously when speculatively executing
18:57:22 <mmu_man> right, you'd implement separate partitions in the same address space in different segments even though they appear as a single linear space
18:57:29 <mmu_man> didn't I say I'd go to sleep
18:57:32 <geist> hah
18:57:33 <orion> efficiency... of what?
18:57:39 <mmu_man> feels almost like when linux doesn't want to pm-suspend
18:57:59 <geist> i have the problem with my windows box. you suspend it and then 10 seconds later it wakes up about 50% of the time
18:58:07 <orion> 21:51:56 < geist> efficiency
18:58:09 <geist> you suspend and then stand there staring at it
18:58:31 <geist> orion: of interrupts and syscalls
18:58:47 <geist> by having something already mapped and already ready, it doesn't have to context switch to get to the kernel
18:58:55 --- quit: grange_c (Quit: Connection closed for inactivity)
18:59:00 <orion> Oh, I didn't realize it saves a context switch.
18:59:06 <geist> at the minimum with the KPTI you still need at least a little trampoline there or you can't get to kernel space
18:59:22 <orion> What's a trampoline?
18:59:38 <geist> a little piece of code that takes the irq/syscall and then does the kernel context switch
18:59:48 <geist> ie, you 'bounce' off it
19:00:31 <izabera> https://www.youtube.com/watch?v=F4RUS23iLls hobby os projects won't ever be this cool
19:00:32 <bslsk05> ​'Microsoft Windows XP TV Commercial (2001)' by thevideorewind (00:00:31)
19:00:50 <geist> oh yeah i remember that one
19:01:00 <geist> dont forget the win95 launch. they got the rolling stones to play, iirc
19:01:04 <orion> If you map the kernel in to user space, does that obviate the need for trampolines?
19:01:41 <geist> yes
19:01:47 <geist> hence why it's more efficient
19:02:04 <geist> the interrupt or syscall goes off, the cpu switches to supervisor mode and then the kernel is already there
19:02:35 <clever> and there is an extra flag in the paging tables, that says only ring0 can access the kernel section
19:02:41 <geist> right
19:02:42 <orion> Oh, a context change and a mode change are not necessarily linked.
19:03:08 <mmu_man> izabera: "yes you can" hmm sounds familiar, who copied who? :)
19:03:54 <izabera> that's from 2004
19:04:11 <orion> The change to supervisor mode happens implicitly when the Instruction Pointer starts executing privileged code (as per the page table). Correct?
19:04:16 <geist> done forget https://www.youtube.com/watch?v=Vhh_GeBPOhs
19:04:17 <bslsk05> ​'Steve Ballmer: Developers' by MrWueb007 (00:00:24)
19:04:41 <clever> orion: i think it can only happen when using special syscall opcodes, to prevent an attacker from just using jmp/call on any kernel address he wants
19:05:00 <mmu_man> orion: entering the kernel means gaining kernel priviliedges, like, entering ring0, which can be done by several ways (interrupt, syscall, call gates), but that only changes the priviledge level
19:05:08 <geist> also in 32bit x86 you *could* use a TSS to switch the address space on a call gate
19:05:15 <geist> but that's also gone in 64bit, and with syscall/sysenter
19:05:24 <mmu_man> clever: yes, if you try a normal jump to a kernel address you get a protection error
19:06:07 <orion> Are protected areas of memory designated in the virtual page tables or are they linked to physical addresses?
19:06:15 <mmu_man> but the kernel entry mechanisms are mostly calls with some checks, so you need somewhere to call
19:06:37 <mmu_man> if your kernel isn't mapped, you need to call elsewhere (a trampoline) and have this small code map the real code
19:06:42 <orion> In other words, could the kernel map itself in to a user space program without such protection?
19:07:32 <mmu_man> the protection is usually either at page level, or at upper level of the page tree
19:07:48 <mmu_man> (it's not really a table, but rather a table of tables...)
19:08:04 <mmu_man> depending on the arch
19:08:53 <mmu_man> and page tables define virtual addresses and their proporties per page, the physical address is just what the mmu returns to the cpu to use
19:09:24 <mmu_man> so the same physical page can be mapped both as a user page and a kernel page with different attributes
19:13:38 <orion> Do trampolines run in user space?
19:14:15 <geist> negative
19:14:53 --- quit: gdh (Quit: Leaving)
19:16:07 <orion> So the trampoline is a piece of kernel code mapped in to user space which signals to the kernel that it needs to interrupt the process and perform all the necessary steps of a context switch.
19:17:04 <geist> not really. it's just a little mini kernel left mapped that has nothing interesting to sploit (if done correctly)
19:17:18 <geist> that is called on irq/syscalls that switches to the real kernel
19:17:21 <geist> hence the trampoline
19:19:24 <orion> Where is the kernel usually mapped within a given user space process?
19:19:34 <geist> depends. but usually 'high'
19:19:45 <geist> as in addresses that are logically greater than user space
19:19:50 --- quit: Belxjander (Ping timeout: 248 seconds)
19:20:00 <geist> (if treated as an unsigned address)
19:20:41 <orion> What's being mapped is a *file*, correct? And that file is, say, /boot/kernel/kernel?
19:21:05 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:21:22 <geist> not really. no
19:21:34 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
19:21:37 <geist> but the kernel is a special case. its loaded by the secondary loader (like grub or whatnot)
19:21:41 <geist> so it just *is*
19:21:56 <geist> as in it wasn't read from anywhere except wherever the loader got it from
19:22:08 <geist> so by the time the kernel starts it was just in memory
19:23:03 <orion> But when a user space process starts, what component does the actual mapping? Is mmap called?
19:23:08 <orion> mapping of the kernel
19:23:08 <geist> yes
19:23:17 <geist> no, the kernel just simply is
19:23:29 <orion> I don't understand what that means.
19:23:29 <geist> the kernel leaves itse'f mapped there because the kernel can do what it wants
19:23:46 <geist> it doesn't need an api to do it, it just simply does it
19:23:47 <rmf1723> It needs to be in the process page tables.
19:23:59 <geist> right, and since the kernel controls the page tabnles, it just leaves itself there
19:24:13 <geist> there is no higher authority in this case
19:24:33 <orion> Is it possible to dump the page tables of a running process?
19:25:02 <geist> not without root access no
19:25:31 <rmf1723> Mapping the kernel can be as simple as copying one PML4 entry
19:27:45 <orion> Is it possible for a process to determine the memory location at which the kernel begins?
19:27:50 <orion> (for itself)
19:28:08 <rmf1723> It's usually always the same
19:28:29 <orion> Ok, how can I determine what it is?
19:28:36 <geist> if it's KASLR, you dont
19:28:41 <geist> unless you sploit the kernel
19:28:43 <geist> that's the point
19:28:49 <rmf1723> Depends on the kernel
19:28:50 --- quit: Belxjander (Ping timeout: 240 seconds)
19:28:52 --- quit: mmu_man (Ping timeout: 255 seconds)
19:29:10 <geist> otherwise if it's not KASLR then it's probably just fixed address and you can figure it out by looking at how the kernel was linked
19:30:05 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
19:30:20 <orion> Let's say I found out where it is. Would I be able to call munmap() on it?
19:30:42 <orion> I like to break things.
19:30:44 <rmf1723> Not without kernel privileges
19:37:28 <Kazinsal> Hrmmmm. Macintosh SE/30 with what looks like bad RAM for eighty bucks shipped.
19:42:12 <jjuran> Switching to 68K to avoid Meltdown and Spectre? :-)
19:42:27 <klys> haw haw
19:44:32 <Kazinsal> Simpler times :)
19:45:40 <Kazinsal> Ooh. Recapped SE for $280 shipped.
19:46:37 --- join: scarecrow (~Legolas@2601:1c0:6b80:497:6911:cf70:8201:d351) joined #osdev
19:48:20 <latentprion> Back to the future
19:50:18 --- join: Phanes (~Phanes@phanes.silogroup.org) joined #osdev
19:50:19 --- quit: Phanes (Changing host)
19:50:19 --- join: Phanes (~Phanes@surro/founder/phanes) joined #osdev
19:54:06 --- join: _chintuS_ (~Legolas@2601:1c0:6b80:497:6911:cf70:8201:d351) joined #osdev
19:54:46 --- quit: _chintuS_ (Remote host closed the connection)
19:58:42 --- quit: scarecrow (Quit: Leaving)
20:01:06 --- join: azonenberg_work (~azonenber@2001:470:ea80:2:2ab2:bdff:fe8a:439b) joined #osdev
20:02:46 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
20:03:41 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
20:03:45 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
20:06:43 --- quit: variable (Client Quit)
20:17:12 --- quit: Phanes (K-Lined)
20:32:44 --- join: Uityyy (~yaaic@2607:fb90:20d4:1dda:c63:2f44:be63:996d) joined #osdev
20:34:14 <Uityyy> Ran Vanadium OS for the first time. Was pleased.
20:34:50 --- quit: Belxjander (Ping timeout: 240 seconds)
20:41:58 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
20:46:07 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
20:50:48 --- join: unixpickle (~alex@2601:645:8103:60b6:880a:a941:4297:a20f) joined #osdev
20:52:08 --- quit: millerti (Ping timeout: 248 seconds)
20:53:58 --- quit: sprocklem (Ping timeout: 252 seconds)
20:56:15 --- quit: mpetch (Ping timeout: 255 seconds)
20:57:28 --- quit: Belxjander (Ping timeout: 240 seconds)
20:59:33 <promach_> I am having some cluttered terminal when I use 'layout src' with minicom. Any help ?
21:02:23 --- join: mpetch (~mpetch@vps2.gnubg.com) joined #osdev
21:03:34 --- quit: Humble (Ping timeout: 240 seconds)
21:04:34 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
21:04:59 --- join: oaken-source (~oaken-sou@p3E9D3249.dip0.t-ipconnect.de) joined #osdev
21:11:03 --- quit: navidr (Quit: Connection closed for inactivity)
21:16:18 --- join: Humble (~hchiramm@2405:204:d20e:c1d6:1a30:2f65:d586:40c2) joined #osdev
21:21:03 --- quit: Belxjander (Ping timeout: 260 seconds)
21:22:24 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
21:26:44 --- join: GautamS (~GautamS@59.182.255.248) joined #osdev
21:28:50 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:33:10 --- quit: pictron (Ping timeout: 248 seconds)
21:40:43 --- join: Yun (~Noon@185.206.225.59) joined #osdev
21:52:22 --- join: pharaun (~pharaun@static.88-198-62-245.clients.your-server.de) joined #osdev
22:00:30 --- quit: osa1 (Remote host closed the connection)
22:00:52 --- join: osa1 (~omer@212.252.142.138) joined #osdev
22:00:52 --- quit: osa1 (Changing host)
22:00:52 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
22:02:06 --- quit: variable (Quit: Found 1 in /dev/zero)
22:06:59 --- join: dmj` (sid72307@gateway/web/irccloud.com/x-vxsxezsnodzoxoss) joined #osdev
22:14:14 --- quit: sdfgsdfg (Remote host closed the connection)
22:17:35 --- join: sdfgsdfg (~yolosdfg@43.230.99.100) joined #osdev
22:18:31 --- quit: sdfgsdfg (Remote host closed the connection)
22:18:45 --- join: sdfgsdfg (~yolosdfg@43.230.99.100) joined #osdev
22:22:39 --- part: sdfgsdfg left #osdev
22:26:51 --- join: user10032 (~Thirteen@90.209.104.11) joined #osdev
22:32:43 --- quit: GautamS (Read error: Connection reset by peer)
22:34:35 --- join: GautamS (~GautamS@59.182.245.10) joined #osdev
22:35:03 <geist> promach_: what the heck is layout src
22:35:15 --- join: C0ckG0bbler (~yolosdfg@43.230.99.100) joined #osdev
22:35:31 --- quit: C0ckG0bbler (Read error: Connection reset by peer)
22:36:08 --- join: C0ckG0bbler (~yolosdfg@43.230.99.100) joined #osdev
22:37:21 --- quit: freakazoid0223 (Quit: First shalt thou take out the Holy Pin. Then, shalt thou count to three. No more. No less.)
22:37:23 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:37:37 --- part: C0ckG0bbler left #osdev
22:37:46 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
22:39:50 --- quit: GautamS (Ping timeout: 248 seconds)
22:43:10 --- join: asdfyasyolo (~yolosdfg@66.133.74.105) joined #osdev
22:44:00 --- quit: asdfyasyolo (Read error: Connection reset by peer)
22:44:15 --- join: asdfyasyolo (~yolosdfg@66.133.74.105) joined #osdev
22:45:18 --- quit: dbittman (Ping timeout: 250 seconds)
22:45:30 --- quit: asdfyasyolo (Read error: Connection reset by peer)
22:45:46 --- join: asdfyasyolo (~yolosdfg@66.133.74.105) joined #osdev
22:47:57 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-cudihurtuvpkljfb) joined #osdev
22:47:57 --- part: asdfyasyolo left #osdev
22:48:43 --- join: KidBeta (~textual@220-244-156-86.tpgi.com.au) joined #osdev
22:49:10 --- quit: KidBeta (Changing host)
22:49:10 --- join: KidBeta (~textual@hpavc/kidbeta) joined #osdev
22:51:11 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
22:52:58 --- nick: Arcaelyx_ -> Arcaelyx
22:56:37 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
22:57:20 --- nick: sdfgsdfg -> sdfsfdg
23:00:43 --- quit: sdfsfdg (Client Quit)
23:01:09 --- join: xenos1984 (~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120) joined #osdev
23:05:38 --- quit: Pessimist (Remote host closed the connection)
23:09:22 --- quit: zesterer (Remote host closed the connection)
23:19:26 --- quit: Humble (Quit: Leaving)
23:19:38 --- join: Humble (~hchiramm@2405:204:d20e:c1d6:8cc1:e44a:314:e56c) joined #osdev
23:22:46 --- quit: Belxjander (Ping timeout: 256 seconds)
23:24:52 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:34:48 --- quit: daniele_athome (Ping timeout: 248 seconds)
23:35:24 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
23:36:24 --- quit: srjek (Ping timeout: 276 seconds)
23:40:52 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
23:49:17 --- quit: KidBeta (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:50:31 --- quit: garit2 (Ping timeout: 252 seconds)
23:51:10 --- join: garit (~garit@94.197.121.185.threembb.co.uk) joined #osdev
23:51:10 --- quit: garit (Changing host)
23:51:10 --- join: garit (~garit@unaffiliated/garit) joined #osdev
23:55:45 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
23:56:11 --- join: KidBeta (~textual@220-244-156-86.tpgi.com.au) joined #osdev
23:56:50 --- quit: Belxjander (Ping timeout: 240 seconds)
23:57:13 --- quit: sdfgsdfg (Remote host closed the connection)
23:57:33 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
23:57:52 --- quit: sdfgsdfg (Max SendQ exceeded)
23:59:02 --- join: inode (~inode@unaffiliated/inode) joined #osdev
23:59:59 --- log: ended osdev/18.01.04