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=13
00:00:00 --- log: started osdev/18.01.13
00:00:06 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:14:11 --- join: xerpi (~xerpi@67.red-83-45-193.dynamicip.rima-tde.net) joined #osdev
00:17:09 --- join: navidr (uid112413@gateway/web/irccloud.com/x-yjdumhfvohsrxpso) joined #osdev
00:19:55 --- quit: air (Ping timeout: 264 seconds)
00:21:41 --- quit: Belxjander (Ping timeout: 248 seconds)
00:23:55 --- join: air (~brand@c-73-63-48-70.hsd1.ut.comcast.net) joined #osdev
00:26:45 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:43:11 --- quit: Belxjander (Ping timeout: 256 seconds)
00:45:08 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:47:08 --- join: oaken-source (~oaken-sou@p3E9D20C6.dip0.t-ipconnect.de) joined #osdev
00:47:23 <m712> i'm trying to understand the frequency divider but am having some trouble
00:47:54 <m712> does it divide the 1193182 by F to get the correct hertz value?
00:49:49 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
00:52:01 <Mutabah> Yes
00:55:36 --- join: silipwn (~silipwn@unaffiliated/silipwn) joined #osdev
00:57:41 <latentprion> Should I see jumanji or darkest hour?
00:58:05 <m712> Mutabah: so using basic maths, 1193182 / Hz = F :P
00:58:18 <m712> doug16k: https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/cpu/legacy_pit.cc#L76
00:58:20 <bslsk05> github.com: dgos/legacy_pit.cc at master · doug65536/dgos · GitHub
00:58:24 <m712> i think you don't need this
01:01:15 <latentprion> Gonna see jumanji
01:04:36 --- join: m_t (~m_t@p5DDA278A.dip0.t-ipconnect.de) joined #osdev
01:05:41 --- join: reavengr2y (~reavengre@unaffiliated/reavengrey) joined #osdev
01:11:03 --- join: reavengr3y (~reavengre@202-161-103-213.tpgi.com.au) joined #osdev
01:11:04 --- quit: reavengr2y (Read error: Connection reset by peer)
01:12:02 --- join: Asu (~sdelang@AMarseille-658-1-125-96.w86-219.abo.wanadoo.fr) joined #osdev
01:12:16 --- join: ybyourmo3 (~reavengre@1.129.109.9) joined #osdev
01:16:06 --- quit: reavengr3y (Ping timeout: 255 seconds)
01:17:09 --- join: m3nt4L (~asvos@2a02:587:a019:8300:3285:a9ff:fe8f:665d) joined #osdev
01:21:58 --- quit: silipwn (Ping timeout: 256 seconds)
01:25:46 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
01:26:20 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
01:27:02 --- quit: hmmmmm (Remote host closed the connection)
01:27:46 <m712> HEY!
01:27:58 <m712> i'm having dots printed on the screen at 50Hz
01:28:02 <m712> holy smoking gun
01:28:22 <m712> it just works
01:33:47 <variable> m712: \o/
01:34:02 <variable> I love how this channel gets excited by print('.')
01:34:22 <_mjg> well i'm not amused
01:34:34 <variable> _mjg: why not?
01:34:59 <_mjg> i remember the accidental rainbow i generated while being off by one in the vga driver
01:35:20 <_mjg> for a rather generous value of "random"
01:35:23 <sdfgsdfg> that sounds very fun
01:35:23 <_mjg> erm, rainbow
01:35:51 <sdfgsdfg> reminds me of that bit I flipped and it pushed my grandmother down the stairs
01:36:20 <variable> um....
01:37:21 <_mjg> good thing you have another one
01:42:38 <m712> variable: btw you guessed it almost right, it's exactly print(".");
01:43:08 <variable> m712: 2 bytes instead of one? thats completely unoptimized
01:43:13 <variable> :-)
01:44:18 <m712> i couldn't bother
01:44:25 <m712> >while (timer_get_ns() < target);
01:44:35 <m712> no kernel thread yet ;_;
01:50:28 <doug16k> m712, why don't I need that?
01:52:52 --- join: silipwn (~silipwn@111.93.99.180) joined #osdev
01:52:53 --- quit: silipwn (Changing host)
01:52:53 --- join: silipwn (~silipwn@unaffiliated/silipwn) joined #osdev
01:53:26 <doug16k> it allows it to be exact on average
01:54:54 <m712> doug16k: i didn't see you using it anywhere
01:55:20 <geist> grats
01:56:07 <doug16k> ah, you're right, I used to use it
01:57:42 <m712> i can sleep now
01:57:49 <m712> (although at 100% cpu :()
01:58:05 <doug16k> m712, you should halt in the spin loop
01:58:14 --- quit: silipwn (Ping timeout: 248 seconds)
01:58:15 <doug16k> the timer IRQ will wake it up
01:58:17 <m712> doug16k: hm, that could help.
01:58:21 <m712> lemme see
02:04:26 <m712> i need to implement arch-dependent halt
02:05:42 <m712> it works
02:05:57 <m712> i also added the ability to set an error message and make the IRQ fail
02:06:04 <m712> in which case the OS halts
02:06:15 <m712> with a register dump and such
02:08:45 <doug16k> if you avoid excessively spinning and burning up the cpu, you will get better turbo boost and no chance of thermal throttling issue
02:09:25 <doug16k> and you won't wreck laptop batteries :)
02:11:08 <m712> i guess
02:11:15 <m712> https://my.mixtape.moe/aogjjh.mkv
02:12:21 <m712> shows the current boot of nOS
02:12:23 --- join: glauxosdever (~alex@ppp-94-66-46-220.home.otenet.gr) joined #osdev
02:13:17 <m712> glauxosdever: o/
02:14:03 <m712> out to lunch
02:18:38 --- quit: Belxjander (Ping timeout: 256 seconds)
02:18:40 <adminseodwn> how many of you kiss your manager's ass at work
02:19:06 --- quit: sinetek__ (Ping timeout: 255 seconds)
02:21:27 <doug16k> I'm not a contortionist, so I never do it
02:21:42 <adminseodwn> but u work right
02:22:07 <doug16k> self employed
02:23:24 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
02:23:26 <adminseodwn> nice
02:23:28 <adminseodwn> business?
02:24:28 <doug16k> when I did work full time I didn't kiss anyone's ass. it's your job to make them love you so much that they kiss your ass
02:26:07 --- join: b3f_ (4dac8cd3@gateway/web/freenode/ip.77.172.140.211) joined #osdev
02:26:44 <doug16k> which is easy when you are in a role you enjoy
02:27:21 <b3f_> how meltdown works with uncached data?
02:27:47 <b3f_> the logic behind is to cache access timing, but when data is not cached?
02:28:06 <doug16k> b3f_, you cause it to access it first, then you do the attack
02:29:00 <b3f_> can you elaborate please? I don't get it
02:29:04 <doug16k> the timing phase is when you time whether it wrote one place or another, dependent on the kernel data, in your memory
02:29:36 <doug16k> when the cpu writes to memory, it will pull the destination cache line into the cache, this is called a "write allocate" cache
02:29:51 <b3f_> the timing phase is used to see if the unaccessible address has been readed in speculative execution, if so it is cached
02:29:59 <doug16k> no
02:30:46 <doug16k> you set it up so the speculative execution reads the kernel memory, THEN calculates a destination address dependent on the value from kernel memory
02:30:54 <doug16k> that destination address is in your memory
02:31:02 <b3f_> yes
02:31:06 <doug16k> the address of the write depends upon the value it read from the kernel
02:31:24 <doug16k> then you time which _destination_ cache line in your memory got write allocated into the cache
02:32:05 <b3f_> but the timing is on this memory array read, right?
02:32:37 <doug16k> the instruction that reads the kernel doesn't even need to retire, and ideally shouldn't. ideally you have a branch that mispredicts and it speculates into the code that reads the kernel. when it gets to the branch it realizes it should have taken the branch and it doesn't even retire the instructions that do the attack
02:32:37 <b3f_> if it is fast, so the index (kernel address) is in the cache
02:34:09 <adminseodwn> doug16k, are you working remotely/
02:34:15 <doug16k> adminseodwn, yes
02:34:25 <adminseodwn> doug16k, job nature?
02:34:31 <b3f_> doug16k: so how it works with non cached data?
02:34:52 <doug16k> adminseodwn, software development
02:35:05 <adminseodwn> doug16k, freelancer.com?
02:35:24 --- quit: xerpi (Quit: Leaving)
02:35:24 <doug16k> freelancer.com is full of people that post "make facebook for me for $20"
02:35:46 <b3f_> lol
02:35:50 <adminseodwn> then where do you find work
02:37:40 <doug16k> at first I used those sites, if you keep looking you will eventually meet people that want to pay properly for good work
02:38:06 <adminseodwn> so what sites do you use now?
02:38:44 <doug16k> I have several long term clients that keep me busy
02:39:22 <adminseodwn> I see. so through contacts
02:39:49 <doug16k> yeah. at first it was just doing random freelance stuff
02:40:09 <adminseodwn> where are you from if I may ask?/
02:40:15 <doug16k> canada
02:40:18 --- quit: variable (Quit: Found 1 in /dev/zero)
02:40:24 <adminseodwn> here the full time jobs are paying less than freelancing
02:40:29 <adminseodwn> is that the case in canada
02:40:57 <doug16k> that's a pretty sweeping generalization. I don't know the statistics
02:41:48 <adminseodwn> you work for canadian clients?
02:42:17 <adminseodwn> or international
02:42:19 --- quit: daniele_athome (Ping timeout: 240 seconds)
02:42:25 <doug16k> both
02:42:45 <adminseodwn> nice
02:43:04 <adminseodwn> what exactly in software development do you do
02:43:40 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
02:44:02 <doug16k> a lot, everything from embedded systems assembly to web work
02:44:25 <adminseodwn> oh there are jobs available for assembly
02:44:27 <adminseodwn> nice
02:49:01 <doug16k> not web design stuff though, can't stand that crap. web applications are fun though
02:58:23 --- join: caladrius (~quassel@188.25.93.211) joined #osdev
03:03:35 --- join: alphawarrior (~alphawarr@86.109.64.106) joined #osdev
03:03:59 --- nick: alphawarrior -> Guest87252
03:04:31 --- quit: Guest87252 (Client Quit)
03:04:54 --- join: kimundi (~Kimundi@p57A89390.dip0.t-ipconnect.de) joined #osdev
03:05:25 --- quit: adminseodwn (Ping timeout: 256 seconds)
03:05:35 --- join: adminseodwn (~archer@unaffiliated/remcwo9o) joined #osdev
03:09:08 --- join: sinetek_ (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
03:10:16 --- join: alphawarrior (~alphawarr@ec2-54-86-37-36.compute-1.amazonaws.com) joined #osdev
03:17:09 --- quit: sinetek_ (Ping timeout: 255 seconds)
03:17:58 --- join: eivarv (~eivarv@cm-84.215.4.97.getinternet.no) joined #osdev
03:19:51 --- join: Darmor (~Tom@198-91-187-5.cpe.distributel.net) joined #osdev
03:19:57 --- quit: `Ivan (Ping timeout: 240 seconds)
03:26:45 --- join: sinetek_ (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
03:42:21 --- quit: Belxjander (Ping timeout: 255 seconds)
03:42:48 --- quit: sinetek_ (Ping timeout: 255 seconds)
03:44:28 --- join: sinetek_ (~sinetek@172.110.128.40) joined #osdev
03:47:34 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
03:50:16 --- join: `Ivan (~tapz@stalkr.net) joined #osdev
04:00:54 --- quit: Belxjander (Ping timeout: 248 seconds)
04:03:21 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
04:10:46 --- join: fujisan (uid4207@gateway/web/irccloud.com/x-stdqcybleslccpou) joined #osdev
04:13:27 --- join: dennis95 (~dennis@p50915DBA.dip0.t-ipconnect.de) joined #osdev
04:19:49 --- join: alphawarrior_ (~alphawarr@86.109.64.106) joined #osdev
04:20:27 --- quit: because (Ping timeout: 268 seconds)
04:21:28 --- quit: ybyourmo3 (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
04:24:32 --- quit: shikhin (Ping timeout: 252 seconds)
04:25:21 --- join: alyptik (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
04:26:29 --- join: shikhin (shikhin@buttsex.space) joined #osdev
04:30:03 --- quit: Belxjander (Ping timeout: 276 seconds)
04:31:23 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
04:33:57 --- join: curiosity_freak (~naveen@157.50.9.15) joined #osdev
04:35:47 <curiosity_freak> memory mapping is implemented by hardware or we can change how memory is mapped using cpu instructions?
04:36:50 <curiosity_freak> guys....................................
04:36:59 <curiosity_freak> anyone here ?
04:37:51 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
04:37:55 <darklink> memory mapping without paging is defined entirely by hardware
04:38:09 <darklink> with paging the virtual memory map is defined entirely by the kernel
04:38:51 <curiosity_freak> so bios rom is mapped to particular address and it is implemented by hardware design? am i right ?
04:39:07 <glauxosdever> Yeah, look up paging (although segmentation is another method)
04:39:24 <Mutabah> curiosity_freak: So.... this gets a little complex as you dig into it
04:39:32 <Mutabah> curiosity_freak: You know about virtual vs physical addressing right?
04:39:34 <Kazinsal> chipset bringup is... messy
04:40:03 <darklink> where the rom is mapped to is defined by the chipset
04:40:15 <darklink> which may support things like remapping
04:40:22 <darklink> same with ram by the way
04:40:42 <darklink> but chipsets are generally incompatible with each other and there are a ton of them
04:40:50 <Kazinsal> I really need to sit down and read through coreboot to see what it does for a lot of chipsets
04:41:04 <darklink> why don't you use virtual addressing?
04:41:25 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
04:41:48 <curiosity_freak> i am trying to understand how BIOS ROM is mapped during boot process of x86 32 bit processor
04:41:50 <darklink> this is supported on all x86 cpus after the 386
04:42:15 <darklink> the bios rom is always mapped at 0xFFFFFFF0
04:42:27 <darklink> or at least there is the entry point of a x86 cpu
04:42:40 <Kazinsal> The reset vector is 0xFFFFFFF0
04:43:08 <darklink> the bios rom is generally mapped at the end of the memory on x86
04:43:13 <Kazinsal> Implemented as real mode CS=0xF000,base=0xFFFF0000 IP=0xFFF0
04:43:25 <curiosity_freak> but as CPU starts in real mode it can't access more than 1MB memory
04:43:32 <darklink> it can
04:43:36 <Kazinsal> Well, that's not entirely true.
04:43:41 <darklink> not easily
04:43:50 <curiosity_freak> then how it will access 0xFFFFFFFF0
04:43:59 <curiosity_freak> this is what i can't understand
04:44:09 <darklink> CS base is at 0xFFFF0000
04:44:11 <Kazinsal> The CS selector is temporarily loaded with a hardcoded segment descriptor cache that has a base of 0xFFFF0000
04:44:38 <Kazinsal> Basically at reset the CPU is in "unreal mode" with a non-zero CS base until it does a far jump.
04:45:04 <darklink> oh wait, so unreal mode is just that the CS base is non-zero?
04:45:29 <Mutabah> darklink: Nah, it's where the cache is programmed in a way that isn't usually possible in real mode
04:45:34 <darklink> (or DS, ES, FS, GS, SS etc)
04:45:36 <darklink> oh
04:45:46 <Kazinsal> Unreal is where you fiddle with the caches for the data selectors
04:45:56 <curiosity_freak> kazinsal: will you suggest some books or website that explains CS Base and reset vector
04:46:06 <Kazinsal> I believe "huge unreal mode" is where you fiddle with the caches for the code selector
04:46:19 <Kazinsal> curiosity_freak: Intel manuals, as always for this
04:47:05 <curiosity_freak> kazinsal: which volume?
04:47:27 <Kazinsal> Uh, I don't know offhand. Probably the first one since it's architecture stuff
04:48:40 <curiosity_freak> CS selctor is 16 bit , right?
04:49:23 <curiosity_freak> but how can it store , CS=0xF000,base=0xFFFF0000 both
04:49:51 <Kazinsal> Segment descriptor caches.
04:50:58 <Kazinsal> When you load a segment register in real mode, internally it sets the base to the value you're loading shifted left by four
04:51:10 <curiosity_freak> kazinsal: which book you use for learning os dev? how did you able to learn each and every detail?
04:51:13 <Kazinsal> That goes in the segment descriptor cache.
04:52:00 <Kazinsal> At reset, the segment descriptor caches are loaded with preset values, which for CS has the base set to 0xFFFF0000 and the visible CS register is set to 0xF000.
04:52:40 <Kazinsal> I don't know everything. If there's something I want to learn, I go find the manual for it, or the datasheets, or the programmer's guides, or the standards implementation manual, or whatever.
04:53:01 <Kazinsal> All of the details for Intel's implementation of the x86 are in their Software Developer Manuals.
04:53:08 --- quit: Darmor (Quit: Leaving)
04:53:20 <Kazinsal> Similarly the details for AMD's implementation are in their manuals, whatever they're called.
04:53:25 <curiosity_freak> thank you kazinsal ! for past two i got stuck with this !!! thank you so much!!!!!!!
04:53:58 <Kazinsal> Ah, AMD64 Architecture Programmer's Manual
04:54:03 <Kazinsal> No problem, glad I could help
04:54:22 <Kazinsal> As you get further into osdev you start to just absorb all sorts of knowledge.
04:54:57 <curiosity_freak> bios's first byte is executed by CPU and it is far jump?
04:55:12 <Mutabah> That's up to the firmware
04:55:19 <Mutabah> (I'd assume it often is)
04:55:22 --- join: mmu_man (~revol@vaf26-2-82-244-111-82.fbx.proxad.net) joined #osdev
04:55:30 <Kazinsal> I think usually there's a couple instructions to set up a stack and then a far jump. I'm not 100% sure
04:55:32 <Mutabah> Or maybe a jump backwards
04:55:59 <Kazinsal> The far jump clears resets the CS descriptor cache base to what it should be
04:56:42 <Kazinsal> (Bad Things can happen if your CS register looks right at the assembly level but the actual "meaning" of what's in the CS register doesn't match the descriptor cache.)
04:57:03 <Kazinsal> (Thankfully that's the kind of thing that only happens in the case of RESET being asserted.)
04:58:25 <curiosity_freak> bios is directly getting executed for a while and it's copies itself to ram and then it executes from RAM?
04:58:55 <Kazinsal> Sometimes there's shadowing but often it'll just execute straight from ROM
04:59:05 <Kazinsal> It's a chipset-dependent thing
05:00:12 <curiosity_freak> how can i find what is happening in my laptop during boot time?
05:05:56 <Kazinsal> Unfortunately I don't know much about modern laptop chipsets and firmware
05:06:05 <Kazinsal> And they're usually "black boxes" so to speak
05:06:20 <Mutabah> curiosity_freak: You can find general information in lots of places - some googlgin about how x86 processors boot can show you a bit
05:06:30 <Mutabah> curiosity_freak: but specifics for hardware, that's a VERY different situation
05:08:35 <curiosity_freak> i serached a lot in google , some sources said that x86 32 bit processors boots in real mode and some other says it boots in unreal mode
05:09:08 <Mutabah> unreal is real mode
05:09:29 <curiosity_freak> but what is the difference between unreal mode and real mode?
05:09:38 <Mutabah> It's what we said earlier
05:09:56 <Mutabah> It's real mode, but the segment caches have values that aren't generally loadable in real mode
05:09:56 <Kazinsal> Unreal mode isn't a separate mode -- it's basically just a way of temporarily using protected mode to load a 32-bit data segment descriptor cache into your data segments before returning to real mode
05:11:03 <curiosity_freak> okay. thanks
05:12:30 <Kazinsal> Hrm. 5am. I should probably get some sleep.
05:16:53 --- quit: curiosity_freak (Ping timeout: 256 seconds)
05:24:11 --- join: uvgroovy (~uvgroovy@c-65-96-163-219.hsd1.ma.comcast.net) joined #osdev
05:24:29 --- quit: Asu (Read error: Connection reset by peer)
05:25:27 --- quit: uvgroovy (Client Quit)
05:25:44 --- join: uvgroovy (~uvgroovy@c-65-96-163-219.hsd1.ma.comcast.net) joined #osdev
05:29:54 --- quit: vdamewood (Ping timeout: 255 seconds)
05:34:26 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
05:36:30 --- quit: sinetek_ (Quit: This computer has gone to sleep)
05:37:32 --- quit: caladrius (Ping timeout: 256 seconds)
05:48:20 --- join: _sfiguser (~sfigguser@5.102.4.85) joined #osdev
05:52:01 --- quit: daniele_athome (Ping timeout: 256 seconds)
05:52:23 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
06:09:40 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
06:11:14 --- join: regreg (~regreg@85.121.54.224) joined #osdev
06:12:40 --- join: curiosity_freak (~naveen@157.50.10.210) joined #osdev
06:13:06 --- quit: immibis (Ping timeout: 255 seconds)
06:25:42 --- join: Asu (~sdelang@AMarseille-658-1-125-96.w86-219.abo.wanadoo.fr) joined #osdev
06:31:01 --- join: JusticeEX (~justiceex@pool-108-30-196-198.nycmny.fios.verizon.net) joined #osdev
06:33:24 --- quit: b3f_ (Quit: Page closed)
06:33:57 --- quit: curiosity_freak (Ping timeout: 256 seconds)
06:35:01 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
06:37:09 --- quit: Belxjander (Ping timeout: 248 seconds)
06:37:11 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
06:40:03 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
06:45:36 --- join: darkvaderXD2016 (~isaac@120.28.160.214) joined #osdev
06:45:38 <darkvaderXD2016> Hello there
06:45:49 <latentprion> hello here
06:47:38 --- join: tacco\unfoog (~tacco@ipservice-092-211-117-156.092.211.pools.vodafone-ip.de) joined #osdev
06:54:11 <darkvaderXD2016> My question is what is the error means of unhandled interrupt: 0x8
06:54:22 <m712> darkvaderXD2016: which interrupt
06:54:40 <m712> oh interrupt 8?
06:55:55 <darkvaderXD2016> yes
06:56:03 <m712> darkvaderXD2016: it's a double fault
06:56:44 <m712> when you don't have a handler for an error interrupt this happens
06:58:34 --- join: xerpi (~xerpi@67.red-83-45-193.dynamicip.rima-tde.net) joined #osdev
06:59:33 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
06:59:45 <darkvaderXD2016> Oh
07:03:54 --- join: curiosity_freak (~naveen@157.50.10.210) joined #osdev
07:07:12 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
07:09:51 <darkvaderXD2016> What problem does it mean?
07:10:01 <m712> i just explained it
07:10:18 <m712> you don't have an interrupt handler for the error you first got
07:10:32 <curiosity_freak> during booting at what address bios rom gets mapped ( starting address of the bios rom )?
07:11:32 <m712> it may or may not get mapped
07:11:43 <m712> but it's within the first 640K for sure
07:11:49 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
07:12:03 <m712> where exactly it gets mapped is implementation-specific
07:12:35 <curiosity_freak> but reset vector is FFFFFFF0H , this where the cpu finds it first instruction to execute
07:12:46 <m712> that's hardcoded
07:12:57 <curiosity_freak> yeah!
07:13:09 <m712> the first instruction usually makes you jump within the beginning of the address space
07:13:16 <m712> wherever the BIOS is
07:13:36 <m712> curiosity_freak: also, you do not have to quit after you get your question answered. just idle here and ask questions you come up with. someone else might also answer your question after you quit, which you don't get to see.
07:13:39 <curiosity_freak> yeah where the first instruction ( jmp ) is stored?
07:13:46 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
07:13:46 <m712> 0xFFFFFFF0
07:15:13 <curiosity_freak> :-) 0xFFFFFFF0 address is mapped to ROM or RAM ?
07:15:48 <curiosity_freak> a system can have only 1GB of RAM , so what happens when it tries to access 0xFFFFFFFF0
07:16:42 <curiosity_freak> anybody here?
07:17:13 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
07:18:18 <m712> it's mapped to a special part of the ROM i think
07:18:34 <curiosity_freak> this is where i got stuck
07:18:40 --- quit: ZeDestructor (Quit: o.O)
07:19:03 <m712> the cpu starts in unreal mode at 0xFFFFFFF0, executes the instructions (which are usually a segment fix and then jmp) and goes to the bios in real mode
07:21:32 <curiosity_freak> okay! i understood
07:22:37 --- join: ZeDestructor (~ZD@unaffiliated/zedestructor) joined #osdev
07:22:58 <curiosity_freak> during unreal mode , even the ram is not initialized , right? so the BIOS ROM must be mapped somewhere so the cpu could find the code 0xFFFFFFF0
07:23:24 <m712> don't really know how
07:24:40 <curiosity_freak> it's okay! even on internet there is no info about it
07:25:01 <curiosity_freak> the jmp instruction will jmp where?
07:28:41 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
07:29:54 --- quit: heat (Client Quit)
07:30:18 --- quit: Belxjander (Ping timeout: 256 seconds)
07:35:05 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
07:36:16 <m712> curiosity_freak: wherever the bios rom is mapped to
07:36:23 <m712> which is implementation defined
07:37:54 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
07:39:10 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
07:40:05 <curiosity_freak> by intel or by hardware manufactures ?
07:40:11 --- join: Asu` (~sdelang@80.12.42.209) joined #osdev
07:40:14 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
07:40:15 --- quit: darkvaderXD2016 (Ping timeout: 256 seconds)
07:40:24 --- quit: Asu (Ping timeout: 255 seconds)
07:52:51 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
07:54:48 --- quit: curiosity_freak (Ping timeout: 276 seconds)
07:57:41 --- join: appa2 (~appa@2607:fcc8:7540:f100:e876:eabf:e4ce:d89c) joined #osdev
08:00:23 --- quit: ExtremeFMan (Remote host closed the connection)
08:00:39 --- quit: sdfgsdfg (Ping timeout: 256 seconds)
08:00:51 --- join: ExtremeFMan (~fooman@dyt4hntqlz3w7pk91v15t-4.rev.dnainternet.fi) joined #osdev
08:06:20 --- join: Asu (~sdelang@AMarseille-658-1-125-96.w86-219.abo.wanadoo.fr) joined #osdev
08:09:58 --- quit: Asu` (Ping timeout: 256 seconds)
08:10:56 --- quit: alphawarrior_ (Quit: Leaving)
08:11:20 --- join: svk (~svk@p2003006A6513E900AC5EA9D97FA7A2A3.dip0.t-ipconnect.de) joined #osdev
08:24:03 --- quit: Asu (Remote host closed the connection)
08:24:18 --- join: Asu (~sdelang@AMarseille-658-1-125-96.w86-219.abo.wanadoo.fr) joined #osdev
08:25:50 --- join: nzoueidi (~nzoueidi@ubuntu/member/na3il) joined #osdev
08:29:13 --- quit: xerpi (Quit: Leaving)
08:35:48 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
08:37:10 --- join: bm371613 (~bartek@2a02:a317:603f:9800:391:ed9f:1c09:1285) joined #osdev
08:42:08 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
08:45:12 --- quit: regreg (Ping timeout: 255 seconds)
08:45:46 --- quit: navidr (Quit: Connection closed for inactivity)
08:48:48 --- quit: mmu_man (Ping timeout: 255 seconds)
08:50:15 --- join: quc (~quc@host-89-230-164-23.dynamic.mm.pl) joined #osdev
08:55:52 --- join: curiosity_freak (~naveen@157.50.10.210) joined #osdev
08:56:26 --- quit: Belxjander (Ping timeout: 256 seconds)
08:57:11 <curiosity_freak> memory mapped io and port mapped io are implemented by hardware or it is implemented by kernel developers
08:57:13 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
08:59:42 --- join: caladrius (~quassel@188.25.93.211) joined #osdev
09:01:09 <curiosity_freak> anyone active here?
09:01:24 <Asu> curiosity_freak: mmio is hardware
09:03:37 --- join: Retr0id (~Retr0id@unaffiliated/retr0id) joined #osdev
09:04:50 --- quit: bm371613 (Quit: Konversation terminated!)
09:04:59 <curiosity_freak> intel uses memory mmio or port mapped io ?
09:05:40 <curiosity_freak> ASU: what is the difference between mmio and pmio ? which is better and why?
09:06:21 --- quit: appa2 (Ping timeout: 255 seconds)
09:06:42 <Asu> mmio is interaction with peripherials through memory reads and writes, whereas pmio is interaction with peripherials through dedicated instructions
09:06:50 <Asu> https://en.wikipedia.org/wiki/Memory-mapped_I/O is a good article on MMIO
09:06:51 <bslsk05> en.wikipedia.org: Memory-mapped I/O - Wikipedia
09:07:08 <Asu> i think PCI primarily uses MMIO but i'm not sure
09:07:19 --- quit: Halofreak1990 (Ping timeout: 256 seconds)
09:07:48 <curiosity_freak> what about intel ?
09:07:53 <curiosity_freak> intel uses mmio?
09:08:06 <Asu> there's both mmio and pmio on x86 iirc
09:08:41 <darklink> yeah, but generally use use mmio because pmio is slow
09:09:08 <curiosity_freak> okay. is there any article on where intel uses mmio and where it uses pmio ?
09:09:19 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
09:09:21 <meowrobot> i wonder how much pmio is used nowadays. intel even never expanded the address space for it.
09:09:26 <Asu> the intel manual maybe?
09:09:34 <Asu> http://wiki.osdev.org/I/O_Ports
09:09:34 <bslsk05> wiki.osdev.org: I/O Ports - OSDev Wiki
09:09:39 <curiosity_freak> okay!
09:09:44 <Asu> pmio is mostly legacy apparently
09:09:53 <Asu> pci and most interesting things don't seem to use port io
09:10:12 <darklink> pmio is used by the linux kernel to callibrate timers
09:10:19 <curiosity_freak> okay.
09:10:20 <darklink> but don't quote me on that
09:10:36 <darklink> pci is completely memory mapped
09:11:05 <Asu> mmio is a cool concept, imo
09:12:05 <curiosity_freak> bios does the memory mapping ?
09:12:09 <darklink> mmio is easier to program
09:12:18 <darklink> because you don't need inline assembly
09:12:26 <darklink> only volatile variables and writes
09:13:50 <curiosity_freak> in mmio we can't have same address pointing to RAM and other device ? a address eithe will point to RAM or A device ?
09:14:50 <darklink> yeah obviously
09:15:09 <darklink> this is why 32 bit machines with 4GB of ram have less than that available
09:15:25 <darklink> because there is a hole in the memory for the mmio devices
09:16:14 <curiosity_freak> yeah i have 2 gb ram , only 1.75 gb available
09:16:21 <darklink> ?
09:16:29 <curiosity_freak> in my laptop
09:16:39 <darklink> i guess 0.25GB are dead then
09:16:46 <darklink> or you only have 1.75 to begin with
09:16:51 --- quit: sortie (Quit: Leaving)
09:16:54 <darklink> because that is only a problem when you have more than 3GB
09:17:22 <curiosity_freak> i am using windows and when see through clicking properties , it shows 1.75 only usable
09:17:49 <darklink> weird
09:18:23 <curiosity_freak> really ?
09:19:19 <meowrobot> are you on 32-bit?
09:19:33 <curiosity_freak> yeah
09:20:01 <curiosity_freak> but hardware is 64 bit , i have installed 32 bit windows os
09:20:09 <Asu> why would you install a 32 bit windows
09:20:23 <Asu> 64 bit is slower
09:20:41 <curiosity_freak> i installed it long ago
09:20:52 <curiosity_freak> those days i don't know much about os
09:21:35 <Asu> euh
09:21:37 <Asu> uh
09:21:41 <Asu> 32 bit is slower i meant
09:22:33 <curiosity_freak> why 32 bit is slower ? bcoz processor uses only extended registers ? i mean eax , ebx like ?
09:23:32 <Asu> for one x86-64 implies SSE2 is there, then there are lacking registers and other reasons i can't think of right now
09:23:37 <darklink> because there are more registers and 64 bit code can count on specific extensions
09:23:41 <darklink> like SSE2
09:23:49 <Asu> ie when you can target x86-64 the compiler will automatically use SSE2
09:24:39 <curiosity_freak> okay. i dual boot ubuntu 64 bit os
09:25:11 --- quit: curiosity_freak (Quit: Leaving)
09:27:06 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
09:32:55 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
09:48:16 --- join: harukomoto (~harukomot@93-41-17-101.ip79.fastwebnet.it) joined #osdev
09:50:53 --- nick: retpoline -> freebooter
09:51:06 --- join: John____ (~John__@79.97.140.214) joined #osdev
09:54:33 --- quit: Belxjander (Ping timeout: 256 seconds)
09:55:26 --- quit: freebooter (Quit: bye)
09:55:46 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
09:59:39 --- quit: nzoueidi (Read error: Connection reset by peer)
10:13:43 --- join: retpoline (~retpoline@90.95.19.47) joined #osdev
10:14:15 --- join: Darmor (~Tom@198-91-187-5.cpe.distributel.net) joined #osdev
10:14:33 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
10:16:22 --- quit: retpoline (Client Quit)
10:16:39 --- quit: Belxjander (Ping timeout: 256 seconds)
10:16:43 --- join: retpoline (~retpoline@90.95.19.47) joined #osdev
10:18:03 --- join: aosfields_ (~aosfields@71.194.3.30) joined #osdev
10:18:09 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
10:18:18 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
10:19:01 --- quit: eivarv (Quit: Sleep)
10:19:13 --- part: rubenwardy left #osdev
10:23:23 --- join: garit (~garit@unaffiliated/garit) joined #osdev
10:29:49 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
10:29:54 --- join: navidr (uid112413@gateway/web/irccloud.com/x-oosswarmnlafgjje) joined #osdev
10:32:53 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
10:38:52 --- join: Lucretia (~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5) joined #osdev
10:38:52 --- quit: Lucretia (Changing host)
10:38:52 --- join: Lucretia (~laguest@pdpc/supporter/active/lucretia) joined #osdev
10:42:31 --- quit: garit (Ping timeout: 256 seconds)
10:45:42 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
10:46:00 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
10:47:05 --- join: mmu_man (~revol@vaf26-2-82-244-111-82.fbx.proxad.net) joined #osdev
10:48:52 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
10:51:28 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
11:02:00 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
11:03:12 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
11:03:42 <sortie> Evening
11:05:06 <rain1> hi
11:05:29 <sortie> What's up?
11:05:52 <rain1> hmm nothing realy
11:06:37 <darklink> hi
11:06:44 --- join: regreg (~regreg@85.121.54.224) joined #osdev
11:07:51 --- quit: regreg_ (Ping timeout: 255 seconds)
11:10:58 <retpoline> hey there Serv-Chan! :)
11:12:16 <sortie> Yo retpoline
11:12:18 --- nick: Asu -> Asu`afk
11:16:00 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
11:16:37 --- join: nzoueidi (~nzoueidi@ubuntu/member/na3il) joined #osdev
11:16:55 --- quit: svk (Quit: Leaving)
11:17:26 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:19:52 <geist> arstechnica had a pretty good summary article of the effects of these fixes
11:20:02 <geist> it looks fairly grim for older cpus without PCID
11:21:05 <sortie> Yeah PCID seems awesome
11:21:37 <geist> problem is PCID is not awesome at all. it's hard to use, very limited, lots of sw complexity to use it well
11:21:44 <geist> which is why it hasn't really been in use until now
11:22:03 <geist> but now it's a necessary evil. to fully utilize it is pretty complicated
11:22:04 <graphitemaster> I think my system may be affected a lot since it's haswell and I think haswell does not have PCID
11:22:27 <sortie> geist: Oh that's a shame. I haven't looked into how it works.
11:22:29 <geist> haswell is the first version that has PCID + INVLPGPCID or whatnot
11:22:47 <geist> apparently PCID was added in westmere, but then haswell added the flush instruction that made it useful
11:22:59 <graphitemaster> geist, yeah but I think I read somewhere that some haswells don't implement it correctly/fully?
11:23:04 <geist> that could be
11:23:42 <graphitemaster> right now I'm running pti kernel with nopti switch because I noticed a significant performance drop since my /home and /root are mount points to a NAS
11:23:53 <geist> yep
11:23:56 <graphitemaster> and NAS perf seems to be really bad
11:24:04 <geist> that's precisely what it hits badly. even with PCID
11:24:28 <geist> file servers, things that hit the network a lot. lots of syscalls
11:24:34 <geist> game servers
11:24:46 <graphitemaster> anything syscall heavy
11:25:02 <graphitemaster> I wonder what this means for vdso.
11:25:41 <graphitemaster> because vdso was meant to take common syscalls (like time queries) and make them a shared library interface in the applications address space to avoid the whole context switch overhead and interrupt overhead where it made sense
11:25:55 <graphitemaster> but that vdso does expose some kernel address space in the application
11:25:58 <geist> i doubt it'd matter
11:26:03 <graphitemaster> does ktpi effectively disable vdso?
11:26:14 <geist> i kinda doubt it, i bet the vdso lives in the trampoline
11:26:28 <geist> or even in the top of the user address space
11:26:47 <geist> that's what we do for zircon. the vdso is simply a shared lib that gets mapped by the kernel, and a page or two of its data segment is patched by the kernel
11:27:41 --- join: appa2 (~appa@2607:fcc8:7540:f100:e876:eabf:e4ce:d89c) joined #osdev
11:27:45 <graphitemaster> That makes sense.
11:28:19 <graphitemaster> So the kernel just patches some data indicating what ever and the interfaces just return the data. So it's effectively copy on change.
11:28:27 <graphitemaster> It's not like a back channel interface to kernel maintained data.
11:28:41 <geist> but iirc the linux vdso is much less sophisticated. it really only provides a) the mechanism for syscalls and b) a short cut for a handful of simple calls
11:28:42 <graphitemaster> It's just a kernel updated view.
11:28:48 <geist> yah
11:29:27 <geist> in some BSDs this has traditionally been called the commpage
11:29:30 <graphitemaster> So it's no different than argv/envp :P
11:30:04 <graphitemaster> (or aux vector)
11:30:22 <graphitemaster> just updated more often.
11:30:31 <geist> right
11:33:51 <geist> now that i remember it, there was some discussion early on with ryzen about some sort of prefetch bug into the no mans land between user and kernel
11:34:08 <geist> and it was because one of the bsds had put their syscall trampoline commpage thing in the top page of user space
11:34:29 <geist> which kind of makes sense if you dont care about ASLR. top of the address space is as good as any
11:35:59 --- quit: rain1 (Quit: WeeChat 2.0.1)
11:36:11 <graphitemaster> I had a neat idea to stop both spectre and meltdown attacks at the cost of twice to three times as much virtual memory space, which may be fine for 64 bit
11:36:27 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
11:36:29 <graphitemaster> at literally no performance cost
11:36:42 <graphitemaster> I just don't know how feasible it would be :P
11:36:45 <geist> i guess the part that i haven't thought aout too much is the type 2 specture stuff. thats much more harder to mitigate
11:36:52 <geist> repolines, etc
11:37:17 <geist> apparently ryzens are mostly immune to at least one of the versions of the BTB attack, because they apparently use full virtual address in their branch tagging
11:37:30 <geist> so you can't generate any false entries like you can with other cpus
11:37:49 <geist> fortunate for them. they had switched to a completely new BTB mechanism for zen
11:38:55 <graphitemaster> The idea was to take stuff like if (index<size) array[index] -> and turn them into r=index<size; if(r) array[!r][index], where every object is backed by a mirrored representation of pages and the mirror pages are not readable
11:39:23 <geist> not writable you mean?
11:39:30 <graphitemaster> so if speculative execution comes along and does array[!r][index], there's an explicit dependency on r, so even if it choose 0, the pages at index from there are not readable/writeable
11:39:40 <graphitemaster> so they won't pull into cache
11:39:45 * geist nods
11:40:22 <graphitemaster> you wouldn't need more memory for this, you're just mirroring the view with different page entries with different permissions
11:40:32 <graphitemaster> it would use significantly more virtual memory tho
11:40:43 <geist> yah but there's no permission combination that is no read/no write
11:40:43 <graphitemaster> and it owuld require padding objects to page sizes
11:40:48 <geist> thats basically no mapping at all
11:41:09 <geist> unless that's really what you mean: reserve the address space and not use it in the mirror section
11:41:24 <graphitemaster> well that or set the tables as cache disabled :P
11:41:38 <graphitemaster> give it its own page directory entry
11:41:41 <graphitemaster> with D off ;-)
11:42:27 <graphitemaster> but yeah there's a few ways of doing this
11:42:59 <graphitemaster> the trick for type 2 spectre stuff would be to put a small execution trapoline in those pages
11:43:09 <graphitemaster> and indirect call through it.
11:43:51 --- quit: appa2 (Ping timeout: 255 seconds)
11:44:04 <geist> retpoline i have to internalize. from what i understand the idea is you generate a series of mispredicted (or mabe predicted) call/rets to basically empty out the BTB before exiting to user space?
11:44:17 <geist> i guess it's because x86 doesnt have an instruction to just dump the BTB like arm does
11:44:54 <geist> apparently this is made worse on haswell+ because those cpus apparently have a backup to consult the BTB if the call/ret cache doesn't have the right entry
11:45:01 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
11:45:03 <graphitemaster> retpoline really is about creating a chain of indirect calls deep enough that it escapes x86's pipeline for speculative execution
11:45:12 <graphitemaster> so the final destination can never be predicted
11:45:18 <graphitemaster> thus executing that function speculatively.
11:45:34 <geist> ah. okay that actually makes some sense. not about trashing the cache, more about completely defeating it
11:45:39 <graphitemaster> yeah
11:46:05 <m712> a hack to fix up intel's mess
11:46:07 <m712> wouldn't just jumping around slow it down tho
11:46:12 <graphitemaster> it's like money laundering, you move it around enough the authorties can't figure out where your money is and steal it.
11:46:57 <m712> i mean, syscall heavy apps (I/O) would slow down by repeated retpolines wouldn't they?
11:47:00 --- nick: Asu`afk -> Asu
11:47:33 <graphitemaster> geist, the other important thing with retpoline is also to jump around in such a way that you cann't predict the order, e.g if the jumps are all some constant N offset from each other (i.e looks like a jump table) then the CPU can still predict the next target location
11:47:47 <graphitemaster> so retpoline is more about randomized jumps.
11:48:09 <graphitemaster> randomized jumps to defeat the cache
11:48:25 <geist> yah i thought i saw some implementation in linux that basically lookedl ike a series of random calls to itself. presumably if you enter it at any point the cpu bounces around i a different pattern like a choose-your-own-adventure book
11:48:26 <retpoline> jesus, so many notifications i thought something at work caught fire on a saturday, lol, i'm having second thoughts about my nick
11:48:29 <geist> but eventually falls out the bottom
11:48:39 <graphitemaster> haha
11:48:40 <geist> yeah retpoline
11:48:53 <retpoline> :) carry on guys :)
11:48:55 <geist> also meltdown and spectre is i bet reconsidering
11:49:18 <geist> also cool, now i dont have to type it. can just tab complete retpoline
11:49:28 <graphitemaster> inb4 gcc graphite loop optimization / intraprocedural analysis bug that creates backdoors gets called graphitemaster
11:49:35 <retpoline> haha
11:50:05 <graphitemaster> geist, wow, retpoline is much easier to type now.
11:50:10 <geist> i know!
11:50:34 <graphitemaster> anyways RETpoline is one of those nasty reality hacks of computer science now.
11:50:38 <retpoline> wish i'd take intel :))
11:51:09 <graphitemaster> 2018 is turning out to be a really bad year for Intel.
11:51:25 <m712> my brain only correlates autocomplete on irc with nicks, so i didn't think of tabbing to retpoline
11:51:31 <graphitemaster> management engine backdoors, amt lock guard security issues, meltdown, etc.
11:51:39 <m712> aka with mentioning someone
11:51:46 --- join: rain1 (~user@unaffiliated/rain1) joined #osdev
11:51:54 <m712> graphitemaster: it's a grand year
11:51:58 <m712> and it's not even feb
11:52:09 <retpoline> we need more people here called "gcc", "kernel", "error" and we can just autocomplete full discussions
11:52:16 <m712> i can't wait to see when SHTF
11:52:34 <m712> retpoline: do not read my mind, rude
11:52:40 --- join: zng_ (~zng@ool-18ba49be.dyn.optonline.net) joined #osdev
11:52:48 --- quit: zng (Read error: Connection reset by peer)
11:53:17 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
11:53:18 --- nick: variable -> constant
11:53:18 --- quit: regreg (Ping timeout: 255 seconds)
11:53:18 <graphitemaster> I herd there is some embargos on ssd firmware that can be used to backdoor ssds.
11:53:21 <constant> retpoline: agreed
11:53:27 <retpoline> m712: sorry, i did use a branch prediction :(
11:53:27 <graphitemaster> for some of the major players like Samsung and Intel.
11:53:33 <graphitemaster> so that'll be interesting
11:54:16 <graphitemaster> at this point computers are about as secure as giving a homeless person your credit card and pin number and telling them to not spend it.
11:54:58 --- quit: jjuran (Quit: jjuran)
11:58:09 <constant> graphitemaster: lol
11:58:22 <darklink> one thing with storage is that both magnetic and solid state require relatively big processing
11:58:29 <constant> graphitemaster: computers were a mistake
11:58:40 <darklink> turing complete computers*
11:58:52 --- quit: meowrobot (Quit: let us connect our intestines and mutually digest)
11:59:14 <darklink> eww
12:00:13 <constant> darklink: eh? turing completeness has do with abstract notion of computation
12:00:46 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
12:01:15 <darklink> well but a turing complete computer can not be used for every single computation that is possible
12:01:17 <rain1> obviously they not actually turing complete, no physical computer is
12:01:17 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
12:01:31 <rain1> he just means that they are very complex and capable
12:01:33 <darklink> yeah the infinite amount of memory kinda is a problem
12:01:57 <constant> it is not possible to build a true manifestation of a turing machine in the universe
12:02:13 <constant> also, C is not turing complete (without file I/O)
12:02:19 <constant> so I fail to see how it matters
12:06:16 --- quit: regreg_ (Ping timeout: 256 seconds)
12:06:20 <m712> constant: lies
12:06:30 <constant> m712: eh?
12:06:42 <m712> just find an exploit in the kernel and use it, then the C program doesn't *do* file IO
12:06:48 <m712> it makes the kernel do it ;)
12:07:07 <constant> m712: why bother finding an exploit in the kernel when you can have the hardware do it
12:07:13 <constant> :-)
12:07:19 <m712> true
12:09:48 --- join: regreg (~regreg@85.121.54.224) joined #osdev
12:10:51 <darklink> also
12:11:19 <darklink> is socket I/O considered file I/O
12:11:33 <darklink> when the destination doesn't save it to disk
12:11:43 <m712> https://www.extremetech.com/computing/262031-researchers-found-another-major-security-flaw-intel-cpus
12:11:44 <bslsk05> www.extremetech.com: Researchers Found Another Major Security Flaw in Intel CPUs - ExtremeTech
12:11:45 --- join: macdonag (~macdonag@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
12:11:49 <m712> c-c-c-c-c-combo breaker
12:12:22 <constant> " an attacker with physical access"
12:12:33 <darklink> yeah
12:12:34 <constant> meh, annoying, but you've lost IMHO
12:12:59 <darklink> physical access = there is a front door and you are using the much more secured back door
12:14:09 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
12:16:35 <Lowl3v3l> wow, its like processors are like every other system out there : once you take a remotely closer look everything falls apart... Fear and panic :D
12:17:51 <rain1> it is MAD!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
12:17:53 <darklink> how close?
12:19:11 <Lowl3v3l> actually its deeply worrying to me that i can name not a single fucking system, program, machine or gadget i consider to be secure anymore or that i am at least confident, will do what it should xD
12:19:35 <constant> Lowl3v3l: "a brick"
12:19:53 <Lowl3v3l> constant: i dont cosider bricks gadets, machines or systems :P
12:20:23 <constant> Lowl3v3l: https://en.wikipedia.org/wiki/Pet_Rock would disagree with you
12:20:23 <bslsk05> en.wikipedia.org: Pet Rock - Wikipedia
12:20:53 <Lowl3v3l> somehow i think we need to rethink all this computing stuff. like have a big manhattan project, collect evertything we have learned in the past 70 years, scrap everything and restart this compuiter stuff
12:21:52 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
12:21:53 <constant> Lowl3v3l: fwiw, that is kind of the goal of the CHERI project https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
12:21:53 <bslsk05> www.cl.cam.ac.uk: Department of Computer Science and Technology: Capability Hardware Enhanced RISC Instructions (CHERI)
12:22:05 <geist> cheri is neat
12:22:21 <Lowl3v3l> never heard of them, though i suspect they are not radical and big enough xD
12:22:24 <constant> geist: why do you say that?
12:22:35 <geist> because it's neat. i'd read into it a bit
12:22:42 <darklink> i have cpus that are not vulnerable to spectre and meltdown
12:22:54 <constant> geist: I mean, just curious what you like about it?
12:22:57 <darklink> tbf they are slow as fuck, but they work
12:23:08 <geist> constant: okay you got me. i haven't read it
12:23:13 <constant> geist: o.O
12:23:16 --- quit: oaken-source (Ping timeout: 256 seconds)
12:23:19 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
12:23:19 <geist> or at least i talked a bit to the guy that worked on it, but not about it directly
12:23:23 --- quit: aosfields_ (Ping timeout: 256 seconds)
12:23:23 <constant> lol
12:23:24 <geist> about uh... other things
12:23:30 <geist> that i dont think i can talk about
12:23:35 <geist> but you had to ask. so there you go
12:23:35 <constant> geist: that wasn't my goal...
12:23:36 <constant> meh
12:23:41 <Lowl3v3l> darklink: its not only spectre and meltdown that i am worryed about. The stuiff that is not shown to be broken usually has major design flaws as well :D
12:23:44 * constant blames geist for all his problems
12:24:13 <geist> it was more like 'see how cheri and fuchsia are similar or different and see if any things apply to us'
12:24:18 <geist> that was what i was looking at it as
12:24:25 <constant> geist: ah
12:24:25 <rain1> qhow about a quick rundown on CHERI
12:24:36 <darklink> well those cpus don't execute speculatively
12:24:49 <geist> turns out, aside from lack of hardware support, that the memory tagging and whatnot would likely work faily well with the way the kernel does capabilities
12:25:20 <rain1> CHERI capabilities are a new hardware data type intended to support the robust and secure implementation of pointers
12:25:23 <rain1> ah, secure pointers
12:25:35 <rain1> Capabilities hold a virtual address as well as metadata describing the memory resources referenced by the pointer (bounds, permissions, ...)
12:25:38 <rain1> thats neat
12:25:40 <geist> right
12:25:43 <mavhq> Looks interesting, really need to implement all the security hacks we've done in software into hardware, do it properly
12:26:06 <Lowl3v3l> darklink: they still run things like a c library for which there is not a single sane implementation yet, mostly use a neumann architecture, are not completely open source , have not be thoroughly tested et cetera... not that nice
12:26:16 <darklink> yeah
12:26:27 <darklink> the specific one i am talking about has a bootrom bug
12:27:11 <darklink> and von neumann architecture
12:27:27 <darklink> although i would wonder how you could load code on a havard architecture
12:27:35 <darklink> also in some cases von neumann is useful
12:27:48 <darklink> like for example in JIT recompilers
12:28:34 <Lowl3v3l> darklink: useful, maybe. a gigantic security flaw? as well :P
12:29:00 <darklink> also some things are unaffected by it
12:29:09 <darklink> like when you smash the stack you can still rop
12:29:15 --- quit: daniele_athome (Ping timeout: 256 seconds)
12:29:22 <darklink> unless you separate the call stack from the main stack completely
12:30:04 --- quit: regreg (Ping timeout: 256 seconds)
12:30:32 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
12:31:42 --- quit: adminseodwn (Ping timeout: 276 seconds)
12:32:19 <darklink> actually i had a stupid idea: a jit recompiler that generates a stack for ROP
12:33:54 <FreeFull> Why not AOT?
12:34:47 <Lowl3v3l> i do consider almost all cases of JIT i know of to be an error as well, so thats not really a big argument to me :P
12:35:27 <darklink> Because what if you want to recompile a JIT?
12:35:39 <darklink> AOT would not work for that
12:35:50 <sortie> "I came here to AOT and JIT and I am all out of time."
12:36:53 <darklink> heh
12:37:27 <rain1> so how is sortix different from linux ?
12:37:51 <sortie> Sortix is Sortix. Linux is Linux.
12:38:43 <_mjg> does your os come with stallman poster?
12:38:51 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
12:39:22 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
12:39:34 <sortie> No I use mandoc for my man pages. I don't use stall man for manuals nor propaganda.
12:39:35 <FreeFull> They're both unixes
12:39:45 <sortie> Woah woah that is a big word
12:39:51 <sortie> Sortix is unix-like
12:40:00 <FreeFull> Ok, they're both unix-like
12:40:01 <glauxosdever> Stall man? Did he stall somewhere?
12:40:14 <glauxosdever> Or, is he s tall?
12:40:37 <sortie> rain1: Well, a key difference is that Sortix has a base system. Linux does not.
12:40:42 <sortie> In many regards, Sortix is closer to BSD
12:40:57 <rain1> ah
12:41:21 <sortie> rain1: Sortix is simple and primitive. That means Sortix doesn't do as much as Linux. On the contrary, Sortix doesn't do as much as Linux.
12:41:41 <sortie> Those awful, awful hacks in Linux? Not there in Sortix.
12:42:10 <glauxosdever> Sortix also supports strlcpy() and strlcat() while glibc usually present on usual Linux distros doesn't.
12:42:40 <glauxosdever> But Sortix also doesn't support multiple CPUs.
12:42:46 <constant> What is sortix ?
12:42:51 <sortie> Yes, yes, but that's a very minor thing to focus on. Besides, that's not the right pattern to use: http://maxsi.org/coding/c-string-creation.html
12:42:52 <bslsk05> maxsi.org: C String Creation
12:42:54 <glauxosdever> An IX that sorts.
12:43:10 <sortie> constant: It's my operating system
12:43:13 <constant> o
12:46:00 --- quit: JusticeEX (Ping timeout: 276 seconds)
12:54:35 --- join: robert_ (~hellspawn@24.96.111.33) joined #osdev
12:54:35 --- quit: robert_ (Changing host)
12:54:35 --- join: robert_ (~hellspawn@objectx/robert) joined #osdev
12:56:45 --- join: regreg (~regreg@85.121.54.224) joined #osdev
13:02:02 --- join: JusticeEX (~justiceex@pool-108-30-196-198.nycmny.fios.verizon.net) joined #osdev
13:04:04 --- quit: regreg (Ping timeout: 256 seconds)
13:04:49 --- join: hmmmm (~sdfgsf@pool-72-79-165-92.sctnpa.east.verizon.net) joined #osdev
13:06:49 <alphawarrior> hello osdev!
13:07:25 <alphawarrior> is it worth spending time on writing a GDT struct to set the GDT up nicely rather than a quick assembly .quad solution?
13:08:18 <constant> alphawarrior: depends on your needs
13:08:33 <alphawarrior> oh I see
13:08:54 <alphawarrior> paging is better than GDT right?
13:09:22 <sortie> alphawarrior: You always need a GDT, even with paging
13:09:29 <alphawarrior> yeah I know that
13:09:43 <sortie> .quad is fine
13:09:43 --- join: rubenwardy (~rubenward@unaffiliated/rubenwardy) joined #osdev
13:09:52 <alphawarrior> but using paging to secure is still better right?
13:10:09 <sortie> It's kinda ortogonal
13:10:21 <sortie> Unless you use the old style segmentation features, but you normally disable that in the GDT
13:10:31 <alphawarrior> oh I see
13:10:46 <alphawarrior> well then I guess I'll stay with the .quad solution and use paging
13:10:48 <sortie> Paging can do much more than segmentation
13:11:00 <alphawarrior> well I still gotta figure it out
13:11:03 --- part: rubenwardy left #osdev
13:11:07 <sortie> alphawarrior: Yeah the GDT is normally static
13:11:13 <constant> segmentation stuff is cool , but no one use[sd] it
13:11:15 <constant> :\
13:11:21 <FreeFull> I forget, was Sortix's libc written entirely from scratch?
13:11:25 <alphawarrior> well yeah esp in 64bit I guess
13:11:29 <sortie> FreeFull: Yep
13:11:45 <alphawarrior> wow a full libc implementation from scratch? how much work is that
13:11:59 <sortie> alphawarrior: Though there's some stuff in the TSS that isn't compile time constants, possibly, like the TSS might refer to a kernel stack. That is usually per-thread so you want to update it.
13:12:16 <sortie> alphawarrior: Not full. Just a bunch. It's a bunch of work?
13:12:42 <alphawarrior> yeah I can imagine so many function :(
13:13:02 <sortie> Writing a libc a large task if you already know how to do it and have lots of experience. It's much larger if you don't already have experience.
13:13:37 <sortie> alphawarrior: Then there's a SMP, where you need a GDT entry per CPU at least
13:13:41 <sortie> (I think?)
13:13:57 <sortie> alphawarrior: This is my example OS with example GDT, TSS support: https://gitlab.com/sortie/myos/
13:13:59 <bslsk05> gitlab.com: Jonas Termansen / Myos · GitLab
13:14:51 <sortie> alphawarrior: A problem with the .quad solution is that if you refer to functions in your TSS, their location might not be compile time constants, and even if they are, your executable format is probably not able to handle "8 upper bits of this symbol" as a relocation
13:15:32 <sortie> https://gitlab.com/sortie/myos/blob/master/kernel/arch/i386/gdt.c#L87
13:15:34 <bslsk05> gitlab.com: kernel/arch/i386/gdt.c · master · Jonas Termansen / Myos · GitLab
13:15:49 --- quit: asecretcat (Quit: let us connect our intestines and mutually digest)
13:15:52 <sortie> In this case, I can't split the address of &tss at compile time, so I need to finish the GDT during early boot
13:16:53 <alphawarrior> oh I see
13:17:08 <alphawarrior> so it's advisable to have some form of c code for it
13:17:29 <sortie> If you must, do it like I do
13:17:44 <alphawarrior> yeah I was thinking of something similar
13:17:51 <sortie> Do not use attribute packed. Build as much as you can at compile time. Don't have a silly gdt_set_gate function.
13:18:04 <sortie> Most common osdev example GDT code is just plain bad
13:18:05 <alphawarrior> oh is the packed attribute bad?
13:18:12 <sortie> alphawarrior: It's not needed
13:18:22 <sortie> alphawarrior: And yes, it often is.
13:18:29 <alphawarrior> does it slow down anything?
13:18:31 <sortie> It makes the compiler generate much worse code
13:18:38 <sortie> It also changes the alignment to 1 byte
13:19:00 <alphawarrior> oh but won't the compiler add padding?
13:19:02 <sortie> And it wouldn't surprise me if the compiler could have bugs, especially if such structures (and their members) are referred to between files
13:19:15 <sortie> And I have no idea how using unaligned members aren't undefined behavior
13:19:21 <alphawarrior> well I actually remember looking at the multiboot.h and trying to find the packed attribute
13:19:26 <sortie> alphawarrior: Padding is normally good. It's added according to rules.
13:19:49 <alphawarrior> so when should I actually use __attribute((packed)) then? which structs need it?
13:20:00 <sortie> alphawarrior: Just do struct { uint16_t limit; uint16_t base_lower; uint16_t base_upper; };
13:20:36 <alphawarrior> oh I see
13:20:47 <sortie> alphawarrior: I recommend simply not using it and simply splitting your variables into multiple variables.
13:20:56 <sortie> This always works and is safe
13:21:07 <alphawarrior> you mean like 2 uint32 instead of a uint64?
13:21:11 <sortie> Yes
13:21:23 <alphawarrior> how big one field should be? native int?
13:21:51 <sortie> alphawarrior: Whatever is needed to match the real CPU structure and its padding (or lack of padding)
13:22:15 <alphawarrior> hmm so 32 bits for x86?
13:22:19 <sortie> alphawarrior: A variable of N bytes requires N byte alignment (64-bit long on 32-bit is an exception, only requires 32-bit alignment)
13:22:28 <sortie> { uint16_t; uint32_t; }
13:22:37 <sortie> This uint32_t is unaligned, so the compiler inserts two bytes before it
13:22:47 <sortie> If the CPU also does that, it is fine
13:22:57 <sortie> If the CPU doesn't do that, you need to split the uint32_t
13:23:03 <alphawarrior> oh wow
13:23:41 <sortie> alphawarrior: Every type in C must be at a memory location that is at least as aligned as the type's alignment requirement. The C compiler adds padding to C structures to enforce this.
13:23:55 <alphawarrior> so actually the packed attribute make this alignment void and makes the cpu do more work to access less long fields?
13:24:08 <sortie> Accessing a C value whose address is not aligned to the value's type is undefined behavior.
13:24:23 <alphawarrior> and as for my 32 bit os I should try to use 32 bits max or split?
13:24:26 <sortie> alphawarrior: Attribute packed makes the compiler read the structure a single byte at a time
13:24:36 <alphawarrior> damn that sounds expensive
13:25:14 <glauxosdever> sortie: I don't think so (at least for x86, where unaligned accesses are allowed).
13:25:25 <glauxosdever> Did you inspect that?
13:25:54 <sortie> glauxosdever: I know what I am saying.
13:25:55 <constant> I love how alpha handled this
13:26:17 <constant> unaligned access result in kernel trap and requires software based emulation
13:26:28 <sortie> glauxosdever: Unaligned accesses are allowed by the x86 CPU, yes, but slow. They are *not* allowed in C regardless of the processor. Attribute packed still does byte reads as far as I know, but not sure.
13:27:02 <glauxosdever> It indeed is highly inefficient, but not more than byte-by-byte reading.
13:27:40 <sortie> Anyways
13:27:45 <alphawarrior> oh so always align your memory correctly by not using attribute((packed)) and split variables to native int size?
13:27:48 --- join: asecretcat (~allisonze@pool-96-236-155-90.pitbpa.fios.verizon.net) joined #osdev
13:27:52 <sortie> This topic is old. Has somebody written an attribute packed wiki article yet?
13:28:20 <glauxosdever> I didn't
13:28:26 <sortie> Do that
13:28:34 <glauxosdever> WHY DID I TALK?
13:29:36 <glauxosdever> Besides, I'm probably not the most knowledgeable about packed attribute
13:29:38 <sortie> alphawarrior: Just don't use attribute packed. If you are dealing with a CPU structure, or a very specific file format with a stupid design, and the format has variables that are at offsets that are not aligned according to the type -- then split the variables to the largest types you can such that they are all properly aligned (you may need to split all the way down to bytes).
13:30:00 --- quit: quc (Remote host closed the connection)
13:30:08 <sortie> alphawarrior: If you are not dealing with a stupid format whose memory layout has unaligned variables, then just write a normal struct.
13:30:16 --- join: quc (~quc@host-89-230-164-23.dynamic.mm.pl) joined #osdev
13:30:22 <constant> just use bitfeilds
13:30:24 <constant> :-)
13:30:35 <alphawarrior> oh well are bitfields properly aligned?
13:30:39 --- nick: constant -> function
13:30:53 <sortie> alphawarrior: On 32-bit, 64-bit types will be automatically accessed as two 32-bit values.
13:30:59 <sortie> I haven't learned to trust bitfields.
13:31:09 <sortie> They have endian problems IIRC?
13:31:13 <function> sortie: I was joking
13:31:21 <function> bit fields are basically a "never use them" function
13:31:25 <alphawarrior> oh so are bitfields deadly?
13:31:33 <alphawarrior> well I used them before
13:31:47 <glauxosdever> sortie: Yep, that's what I've found too some year ago
13:31:52 <sortie> alphawarrior: I just prefer using a plain integer type and macros for bit values.
13:31:53 <function> its basically only useful when you want to pack multiple different bit fields into a single int, but don't ever want to treat them as the same thing
13:32:05 <function> i.e., when shifting is a meaningless operation
13:32:06 <sortie> glauxosdever: That's just how the ABI is, nothing new
13:32:12 <function> and when serialization isn't helpful
13:32:27 <alphawarrior> well there are many bitfields in osdev from what I saw like the GDT has them too
13:32:53 <alphawarrior> well if it's really bad then I won't use them anymore here
13:33:16 <function> alphawarrior: the main issues is that you can't count on (a) lack of padding or (b) endianness
13:33:28 <glauxosdever> Yeah, there are many bitfields unfortunately.
13:33:41 <alphawarrior> oh so could become big endian on my little endian pc?
13:34:24 <alphawarrior> how about a union with an int and a bitfield would that guarantee the endianness?
13:34:25 <glauxosdever> http://wiki.osdev.org/Getting_to_Ring_3#GDT
13:34:26 <bslsk05> wiki.osdev.org: Getting to Ring 3 - OSDev Wiki
13:34:57 <function> glauxosdever: shouldn't that page be replaced with "divorce twice" ?
13:35:40 <alphawarrior> oh a cute bitfield for gdt
13:35:45 <glauxosdever> DUh, it also has the packed attribute.
13:35:57 <alphawarrior> lol
13:36:50 <glauxosdever> No, according to a lot of evidence from masters from the University of OSDev, that "cute bitfield" is bad.
13:36:55 <Ameisen> Trying to build a Cortex M3 binary... an empty binary that just consists of int main... currently has a .TEXT section of 33277 bytes
13:36:56 <Ameisen> ... why
13:37:17 <glauxosdever> Did you disassemble it?
13:37:18 <alphawarrior> it's packed bad waiting for someone to unwrap it
13:38:35 <Ameisen> glauxosdever - not yet. Just thinking out loud
13:38:41 <Ameisen> trying to migrate my AVR project system too ARM
13:38:58 --- quit: macdonag (Quit: macdonag)
13:39:15 --- join: macdonag (~macdonag@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
13:39:39 <function> The <enter> key is broken on my keyboard so I need to use the numpad one
13:39:43 <function> this is only kind of annoying
13:39:50 <function> but the clackity-clack makes it worth it
13:43:32 --- quit: macdonag (Client Quit)
13:43:46 --- join: macdonag (~macdonag@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
13:45:49 --- join: jjuran (~jjuran@c-73-250-47-193.hsd1.md.comcast.net) joined #osdev
13:46:44 <Ameisen> I realized I'm not entirely sure how to set GPIO pins
13:46:57 <Ameisen> I presume this is why Arduino is popular
13:47:19 --- quit: Shamar (Quit: Lost terminal)
13:48:09 <Asu> Ameisen: pretty much, arduino is the easiest solution for newbies
13:48:27 <Asu> or for getting small projects ready fast
13:48:28 <Ameisen> This is technically an arduino board (due) but my environment isn't set up for arduino things for ARM
13:48:36 <Asu> oh, i own a due too
13:48:38 <Asu> you need to install a package
13:48:43 <Ameisen> plus, if I can get a basic ARM environment set up, I'll have a leg up
13:48:43 <Asu> in the arduino ide
13:48:44 <Ameisen> I did install it
13:48:56 <Ameisen> I can't figure out where it installed the configurations, ilbraries, etc in the arduino directory
13:49:09 <Ameisen> I use a separate build system
13:49:11 <Asu> you should just be able to select arduino due as the target board in your sketch
13:49:13 <Asu> ah, ok
13:49:32 <Ameisen> so I'm going over the atmel avr datasheet trying to figure out pin configuration
13:49:34 <Ameisen> :
13:49:36 <Ameisen> :|
13:49:42 <Asu> gl
13:49:42 <Ameisen> my keyboard broke as well, and I'm using a temporary one
13:49:44 <Ameisen> can't type right on it
13:50:08 --- join: b0l_ (4dac8cd3@gateway/web/freenode/ip.77.172.140.211) joined #osdev
13:50:37 --- quit: jjuran (Ping timeout: 260 seconds)
13:50:55 <b0l_> how microcode update works from userspace when all CPUs are already setup?
13:52:17 <rain1> the microcode is specially signed so only intel can provide updates (that the cpu doesnt reject)
13:52:23 <rain1> and the kernel has some code to perform the update
13:52:52 <b0l_> yes, I know this.. but when the CPU is already active how update works?
13:53:04 <b0l_> turn off the CPU, update and re-setup?
13:53:15 <rain1> i think that it requires a reboot to take effect
13:53:26 <rain1> im not an expert though
13:53:36 <b0l_> https://www.kernel.org/doc/Documentation/x86/early-microcode.txt
13:53:43 <b0l_> the legacy methods not
13:54:03 <b0l_> The cached microcode patch is applied when CPUs resume from a sleep state. There are two legacy user space interfaces to load microcode, either through /dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file in sysfs. In addition to these two legacy methods, the early loading method described here is the third method with which microcode can be uploaded to a system's CPUs.
13:54:45 <b0l_> so it seems that during the update the CPU is set in sleep mode and resumed
13:57:49 --- join: xerpi (~xerpi@109.red-83-45-195.dynamicip.rima-tde.net) joined #osdev
14:03:50 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
14:12:29 --- quit: zng_ (Read error: Connection reset by peer)
14:12:56 --- join: zng (~zng@ool-18ba49be.dyn.optonline.net) joined #osdev
14:21:24 --- quit: uvgroovy (Read error: Connection reset by peer)
14:21:26 --- join: uvgroovy_ (~uvgroovy@c-65-96-163-219.hsd1.ma.comcast.net) joined #osdev
14:26:04 --- quit: function (Quit: /dev/null is full)
14:31:59 --- quit: xenos1984 (Quit: Leaving.)
14:32:36 --- quit: harukomoto (Ping timeout: 255 seconds)
14:33:55 --- quit: fujisan (Quit: Connection closed for inactivity)
14:35:38 --- quit: glauxosdever (Quit: leaving)
14:42:06 --- part: CustosL1men left #osdev
14:42:09 --- part: CustosLimen left #osdev
14:46:49 --- quit: sortie (Ping timeout: 240 seconds)
14:48:44 --- quit: retpoline (Quit: bye)
14:48:57 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
14:49:31 --- join: retpoline (~retpoline@kite.riseup.net) joined #osdev
14:53:02 --- quit: Darmor (Quit: Leaving)
15:05:02 --- join: jjuran (~jjuran@c-73-250-47-193.hsd1.md.comcast.net) joined #osdev
15:12:56 --- quit: FreeFull ()
15:13:22 --- join: immibis (~chatzilla@122-59-200-50.jetstream.xtra.co.nz) joined #osdev
15:20:32 --- join: FreeFull (~freefull@defocus/sausage-lover) joined #osdev
15:22:41 --- join: Asu` (~sdelang@80.12.42.209) joined #osdev
15:22:54 --- quit: Asu (Ping timeout: 256 seconds)
15:24:06 --- quit: dennis95 (Quit: Leaving)
15:27:10 --- quit: gattuso (Remote host closed the connection)
15:28:20 --- quit: ahrs (Remote host closed the connection)
15:28:29 --- join: gattuso (~gattuso@pompel.me) joined #osdev
15:29:29 --- join: ahrs (quassel@gateway/vpn/privateinternetaccess/ahrs) joined #osdev
15:32:45 --- quit: Asu` (Remote host closed the connection)
15:32:59 --- join: Asu (~sdelang@80.12.42.209) joined #osdev
15:34:42 --- quit: b0l_ (Quit: Page closed)
15:38:39 --- join: hppavilion[1] (~dosgmowdo@58-0-174-206.gci.net) joined #osdev
15:42:00 --- quit: sortie (Quit: Leaving)
15:43:53 --- quit: m3nt4L (Remote host closed the connection)
15:44:14 --- quit: Tazmain (Quit: Leaving)
15:44:40 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
15:45:52 --- quit: Asu (Quit: Konversation terminated!)
15:51:10 --- quit: xerpi (Quit: Leaving)
15:51:14 --- quit: jjuran (Ping timeout: 256 seconds)
15:54:20 --- quit: mavhq (Read error: Connection reset by peer)
15:55:24 --- quit: caladrius (Ping timeout: 255 seconds)
15:55:35 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
15:56:48 --- quit: macdonag (Quit: macdonag)
15:59:14 --- quit: mavhq (Read error: Connection reset by peer)
16:00:30 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
16:10:01 --- quit: quc (Remote host closed the connection)
16:10:13 --- join: quc (~quc@host-89-230-164-23.dynamic.mm.pl) joined #osdev
16:23:56 --- quit: m_t (Quit: Leaving)
16:31:47 --- quit: caen23 (Ping timeout: 256 seconds)
16:37:42 --- quit: hppavilion[1] (Ping timeout: 256 seconds)
16:40:12 --- quit: babyflakes (Quit: Connection closed for inactivity)
16:55:16 --- quit: nzoueidi (Ping timeout: 256 seconds)
16:57:38 --- join: eivarv (~eivarv@cm-84.215.4.97.getinternet.no) joined #osdev
16:57:44 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
17:02:45 --- quit: caen23 (Ping timeout: 276 seconds)
17:05:31 --- quit: return0e_ (Remote host closed the connection)
17:05:34 --- join: Kimundi_ (~Kimundi@p57A894B0.dip0.t-ipconnect.de) joined #osdev
17:05:52 --- join: return0e (~return0e@87-102-105-145.static.kcom.net.uk) joined #osdev
17:09:15 --- quit: kimundi (Ping timeout: 276 seconds)
17:12:01 --- quit: navidr ()
17:12:09 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
17:16:14 --- quit: mmu_man (Ping timeout: 256 seconds)
17:16:37 --- quit: caen23 (Ping timeout: 248 seconds)
17:18:26 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
17:23:21 --- quit: caen23 (Ping timeout: 256 seconds)
17:24:21 --- quit: epony (Read error: Connection reset by peer)
17:24:50 --- join: epony (~nym@77-85-133-5.ip.btc-net.bg) joined #osdev
17:27:12 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
17:31:42 --- quit: caen23 (Ping timeout: 255 seconds)
17:32:44 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
17:33:32 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
17:35:12 --- quit: awordnot (Ping timeout: 260 seconds)
17:38:05 --- quit: caen23 (Ping timeout: 256 seconds)
17:39:14 --- join: awordnot (~awordnot@67.184.137.130) joined #osdev
17:41:24 --- quit: sortie (Read error: Connection reset by peer)
17:42:12 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
17:46:35 --- quit: caen23 (Ping timeout: 256 seconds)
17:47:16 --- quit: eivarv (Quit: Sleep)
17:50:14 --- quit: daniele_athome (Ping timeout: 256 seconds)
17:50:59 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
17:52:03 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
17:52:24 --- quit: Belxjander (Ping timeout: 255 seconds)
17:54:12 --- quit: Kimundi_ (Ping timeout: 256 seconds)
17:55:33 --- quit: caen23 (Ping timeout: 255 seconds)
17:56:43 <geist> random thing that's neat: https://ucnv.github.io/pnglitch/
17:56:43 <bslsk05> ucnv.github.io: The Art of PNG Glitch
17:56:58 <geist> i new about folks manually glitching jpeg and whatnot, so i think, what about png?
17:57:04 <geist> turns out it's pretty good to glitch
17:57:41 --- quit: asecretcat (Remote host closed the connection)
17:58:41 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
18:00:24 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
18:04:58 --- quit: caen23 (Ping timeout: 256 seconds)
18:13:14 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
18:15:48 --- quit: Belxjander (Ping timeout: 265 seconds)
18:16:53 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
18:17:47 --- quit: caen23 (Ping timeout: 260 seconds)
18:18:49 --- join: asecretcat (~allisonze@pool-96-236-155-90.pitbpa.fios.verizon.net) joined #osdev
18:22:50 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
18:27:38 --- quit: caen23 (Ping timeout: 256 seconds)
18:28:50 <graphitemaster> geist, ever see the windows png glitch?
18:32:13 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
18:34:55 <geist> no, haven't
18:37:01 --- quit: caen23 (Ping timeout: 256 seconds)
18:40:54 <graphitemaster> geist, can't find it, but was a neat bug where you could hide another image inside the png and zooming in on it with any windows app that used window's png implementation would make it visible (photo viewer, ie, paint, etc)
18:41:05 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
18:41:07 <geist> oh cute
18:41:46 <graphitemaster> something like this https://superuser.com/questions/1224233/invisible-png-image-layer-that-is-only-visible-as-a-background
18:41:48 <bslsk05> superuser.com: windows - Invisible PNG Image Layer that is only visible as a background - Super User
18:41:51 <graphitemaster> setting it as a background was another way, yes.
18:43:45 <graphitemaster> ye https://callumcarmicheal.com/resources/superuser/HiddenBackgroundImage.png
18:43:52 <graphitemaster> still works on some things here in linux
18:44:15 --- join: curiosity_freak (~naveen@157.50.10.254) joined #osdev
18:45:30 --- quit: caen23 (Ping timeout: 255 seconds)
18:45:31 --- quit: alyptik (Ping timeout: 256 seconds)
18:47:40 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
18:48:10 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
18:51:17 --- join: multi_io_ (~olaf@x4e31fa06.dyn.telefonica.de) joined #osdev
18:52:15 --- quit: caen23 (Ping timeout: 255 seconds)
18:52:52 --- join: alyptik (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
18:54:22 <curiosity_freak> if memory mapping of a CPU is hardcoded, then how the CPU changes the memory mapping after booting the os?
18:54:57 <Mutabah> It doesn't (change the physical mappings)
18:55:12 --- quit: multi_io (Ping timeout: 276 seconds)
18:55:13 --- quit: tacco\unfoog ()
18:55:27 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
18:55:29 <curiosity_freak> for exambele during bios 0xFFFFFFF0 is mapped to BIOS ROM
18:55:56 <curiosity_freak> and after booting the this address is mapped to RAM if we have 4GB or ABOVE
18:57:38 <asecretcat> it might involve commands sent to the memory controller.
18:57:57 --- quit: Belxjander (Ping timeout: 248 seconds)
18:58:16 <geist> ugh, smells like poo outside
18:58:24 <geist> wonder if some sewer overflowed due to rain or something
18:58:59 <geist> curiosity_freak, asecretcat: yes that's precisely what happens
18:59:16 <geist> but, 0xfffffff0 is < 4GB, so there's a good chance that the bios is still mapped there even after the OS starts
18:59:29 <geist> things like the local apic and whatnot are usually mapped up there
18:59:53 <geist> in practice if you read the intel/amd per cpu does (not the architecture manual) they'll describe the low level registers that generally only the BIOS needs to know about
18:59:56 --- quit: caen23 (Ping timeout: 256 seconds)
19:00:17 <geist> how to set up the raw physical mapping, how to locate the local apic, etc. in AMD it tends to be a bunch of private MSRs up in the 0xc0000000 range
19:00:30 <geist> and intel likes to put a lot of those control bits in pci device 0.0:0's config space
19:00:44 <geist> but the gist is there's probably a control register somewhere that the BIOS set up to configure the machine
19:01:24 <asecretcat> memory maps are a weird thing i've always wondered how they worked.
19:02:06 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
19:02:52 <geist> asecretcat: if you're really curious, AMD documents it fairly well in what they call the BKDG (bios/kernel developer guide) that basically describes all the control registers and how to bootstrap one of their cpus cold
19:02:59 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
19:03:04 <asecretcat> i remember watching this one streamer that was trying to hack his bios and reading over datasheets, he came across registers in the super i/o chip to change addresses it'd respond to.
19:03:05 <geist> how to run out of cache befoe bringing up the dram controller, etc
19:03:12 <asecretcat> ah nice nice
19:03:24 <geist> yah. that stuff isn't magic, it's just a bunch of control bits that you generally just never have to worry about
19:03:36 <geist> intel has a similar thing, though they dont release the docs quite as publically, i think
19:03:49 <geist> but if you look up say the docs for a parituclar skylake family, you can actually get pretty low level stuff
19:04:24 --- quit: JusticeEX (Ping timeout: 255 seconds)
19:04:26 <geist> interesting that if you really wanted you could generally speaking configure either an intel or amd machine to not really look like a PC. ie, the 640k memory hole isn't really hard coded. you can turn it off
19:04:31 <geist> that sort of thing
19:04:34 <curiosity_freak> geist: i am asking about where the BIOS ROM is mapped in CPU address space , ( at what address BIOS begins ) ?
19:05:03 <geist> absolutely. the AMD manual, for example, describes how the cpu loads the initial bootstrap off of SPI flash
19:05:46 <geist> since bios roms are usually not directly addressible anymore. the BIOS usually slurps itself off of spi flash into some memory somewhere and then marks it read only so it looks like rom, from what i understand
19:06:05 <geist> and there are all sorts of control registers to configure that
19:06:11 <curiosity_freak> as i am using intel , i have downloaded 4 manuals and i still can't find anything about memory mapping of BIOS!!! :-(
19:06:31 <geist> bummer. intel isn't quite as good at publically releasing their docs
19:06:43 <geist> or. what you're actually reading is actually telling you what you want to know
19:06:50 <geist> it's just not making a hard policy on how bios works
19:06:54 --- quit: caen23 (Ping timeout: 276 seconds)
19:07:05 <geist> it may be describing he mechanism by which any given bios implementation may configure itself
19:07:14 <geist> but makes no real stand on how it should
19:07:20 <curiosity_freak> 0xFFFFFFF0 this where the bios BEGINS ?
19:07:36 <geist> the answer is 'not really'
19:07:53 <geist> it did at some point, doesn't really anymore
19:07:59 <curiosity_freak> 0xFFFFFFF0 has a jump instruction ?
19:08:20 <geist> clearly you're not getting me. if you want an answer then sure. yes that's what is there
19:08:33 <geist> that's what classically happened on 32bit x86s. say a 486. yes. you put bios there
19:08:41 <geist> does it happen on modern x86s? not really
19:09:12 <curiosity_freak> okay . i am trying to understand you as i am a beginner
19:09:14 <geist> there's the model of what an original x86 did and then there's the real world. and this falls into things that only the bios cares about and thus intel/amd are free to change the mechanism over time
19:09:23 <geist> since bioses are not assumed to be forward compatible with newer chips
19:09:28 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
19:11:01 <geist> that being said, i'm now curious myself
19:11:22 <curiosity_freak> : - )
19:12:53 --- quit: mawk (Quit: WeeChat 1.8)
19:13:04 --- join: mawk (~mawk@deepweb.ninja) joined #osdev
19:13:08 <geist> i had remember glancing over the AMD manual at least and deciding that it probably works this way
19:13:20 <geist> but then i dont know how bioses *really* work in terms of their memory layout
19:14:04 <geist> clearly modern ones are much much larger than the 64k or so they were on an initial IBM PC, and they are i believe generally sitting on non memory addressable flash (SPI flash, etc) so that means they probably need to copy pretty much their entire image into memory somehwere
19:14:06 --- quit: caen23 (Ping timeout: 256 seconds)
19:14:29 <geist> so most likely it's just part of that occupied memory that's generally up high but < 4GB
19:16:23 <curiosity_freak> but what if i have 5GB of ram , and i tried to access 0xFFFFFFF0 after booting , it will still point to BIOS ROM or it will point to RAM?
19:17:04 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
19:18:04 <geist> who knows
19:18:16 <curiosity_freak> : -)
19:18:22 <geist> a third option is 'there's nothing there'
19:18:26 <geist> which is also entirely possible
19:19:04 <curiosity_freak> maybe , but i think it must be there , because it's hardwired right?
19:19:12 <curiosity_freak> we can't change it
19:19:42 <geist> again you're not understanding what i'm saying
19:19:58 <geist> but i'm kind of tired of alking about it, so the answer is 'i have no idea'
19:20:34 <curiosity_freak> okay!!!
19:21:28 --- quit: caen23 (Ping timeout: 256 seconds)
19:24:49 --- quit: Arcaelyx (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:27:13 <geist> well, actually im reading the skylake manual and it absolutely says that FLASH is mapped to 0xffe0.0000 to 4GB (2MB)
19:27:24 <geist> it says it will decode to external flash always, and you can't override it (for security purposes)
19:27:38 <geist> so yes, it's precisely what you say. there's flash there (on intel cpus at least)
19:27:44 <Kazinsal> makes sense -- SMBIOS is probably mapped t here
19:27:50 <Kazinsal> or something similar
19:27:51 --- quit: mrd_ (Ping timeout: 248 seconds)
19:28:04 <Kazinsal> granted inaccessible to ring 0 but for physical addressing purposes
19:28:39 <geist> there's a legacy 64K flash mapping too for dos compatiblity
19:28:47 <geist> what i dont know now is at what offset to flash is it
19:28:53 <geist> and what is the flash interface. spi flash? nor?
19:29:19 <geist> incidentally i'm looking at the '6th gen core family mobile processor lines data sheet'
19:29:37 --- join: SwiftMatt (~Objective@2601:282:4300:3e:e95a:480b:df9d:d143) joined #osdev
19:29:41 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
19:29:45 <geist> which may also work differently than a socketed version, because it's intended to be soldered down and more tightly coupled with things like flash, since it's a mobile version
19:33:48 <curiosity_freak> geist: i found a good source that explains it !! as i am a beginner i can't understand it.
19:34:10 <curiosity_freak> https://www.coreboot.org/Developer_Manual#Intel_Architecture
19:34:11 <bslsk05> www.coreboot.org: Developer Manual - coreboot
19:34:26 <curiosity_freak> if you understand it , please make me understand !!!!
19:34:43 <curiosity_freak> bslsk05: you know how bios is mapped ?
19:34:51 --- quit: caen23 (Ping timeout: 276 seconds)
19:35:03 <geist> yeah bslsk05
19:35:35 <geist> cute, this describes how VGA memory is emulated. it's basicalyl configred to steer accesses to it to a particular BAR of pci device 2, which is the integrated video thing
19:35:52 <curiosity_freak> geist: you got it?
19:35:57 <geist> no i'm reeading another doc
19:36:59 <curiosity_freak> okay! once you got it please make me understand !! i am trying to understand about this for past 3 days
19:37:10 <geist> ehh. not really
19:37:10 --- join: JusticeEX (~justiceex@pool-108-30-196-198.nycmny.fios.verizon.net) joined #osdev
19:37:22 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
19:37:40 <geist> anyway, why are you so interested?
19:38:27 <curiosity_freak> bcoz i wanna create my hobby OS !!!
19:38:38 <geist> you dont need to know any of this to write an OS
19:38:50 <geist> in fact you kind of dont want to. that's the point of the bios. it sets all this crap up so you dont have to care
19:38:56 <rain1> >how bios is mapped
19:39:11 <rain1> would that depend on if its EFI or BIOS
19:39:13 <geist> doesn't matter. once your kernel is started you can just forget bios exist
19:39:23 <rain1> what is bios?
19:39:24 <Kazinsal> in fact you should forget the BIOS exists as soon as humanly possible
19:39:29 <rain1> i dont really know about it
19:39:37 <geist> rain1: absolutely. what i've been trying to tell him is that it's a lot more complicated than he probably thinks, and fairly machine/cpu specific
19:39:52 <geist> because you (the OS) aren't really supposed to care, if it's doing its job
19:39:55 <rain1> isn't it motherboard specific
19:40:01 <geist> rain1: basically, yes.
19:40:10 <curiosity_freak> geist: okay!!! i got it!
19:42:11 --- quit: caen23 (Ping timeout: 256 seconds)
19:42:51 --- quit: SwiftMatt (Quit: Textual IRC Client: www.textualapp.com)
19:44:08 --- quit: Belxjander (Ping timeout: 256 seconds)
19:44:50 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
19:46:20 <curiosity_freak> geist: you have created your own os?
19:46:47 <geist> absolutely
19:47:05 <curiosity_freak> can i have a look at it ?
19:47:11 <geist> sure
19:47:19 <curiosity_freak> created any youtube video for it?
19:47:40 <geist> no
19:48:33 --- quit: John____ (Read error: Connection reset by peer)
19:49:24 --- quit: caen23 (Ping timeout: 255 seconds)
19:51:03 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
19:51:17 <curiosity_freak> geist: uploaded in github ?
19:51:44 <geist> yes. look under 'travisg'
19:52:53 <curiosity_freak> new os ?
19:53:56 <geist> that was my original one, yes
19:54:09 <curiosity_freak> okay !
19:54:16 <curiosity_freak> good work man!!!
19:54:31 <Levex> youtube video lol
19:54:41 <geist> Levex: i know right?
19:54:50 <geist> hell i wrote newos before youtube existed
19:54:56 --- quit: freakazoid0223 (Quit: Live long and prosper \v//)
19:55:02 <curiosity_freak> : - )
19:56:17 --- join: SwiftMatt (~Objective@2601:282:4300:3e:9932:809a:5202:f95a) joined #osdev
19:57:22 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
20:01:49 --- quit: curiosity_freak (Ping timeout: 256 seconds)
20:02:01 --- quit: caen23 (Ping timeout: 256 seconds)
20:02:50 --- quit: JusticeEX (Ping timeout: 256 seconds)
20:05:11 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
20:07:56 --- quit: Belxjander (Ping timeout: 256 seconds)
20:09:01 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
20:09:57 --- quit: caen23 (Ping timeout: 276 seconds)
20:14:08 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
20:19:03 --- quit: caen23 (Ping timeout: 276 seconds)
20:24:04 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
20:24:45 --- join: mrd (~md@debian/developer/mrd) joined #osdev
20:28:48 --- quit: caen23 (Ping timeout: 276 seconds)
20:38:08 <pounce> wow, newos supports a lot of different systems
20:38:18 <pounce> I need to port mine away from x86_64 sometime :<
20:38:50 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
20:41:25 --- quit: Belxjander (Ping timeout: 248 seconds)
20:42:23 <pounce> Also: why do OSes (every one whose code I've read) have a separate kernel stack for each thread/process? Isn't one kernel stack enough? (because the kernel memory mapping is consistant between processes)
20:42:37 <doug16k> pounce, what if you have to context switch?
20:42:54 <doug16k> say, a page fault that blocks on I/O, for example
20:43:45 --- quit: caen23 (Ping timeout: 256 seconds)
20:44:09 <doug16k> it's possible to make that work without separate stacks, but much more cumbersome
20:44:53 <pounce> why would a page fault block? I was aware that ISRs are supposed to be written to return quickly
20:45:01 <pounce> I can see that for a variety of system calls though
20:45:12 <doug16k> because it can't magically make the disk instantly do a read or write
20:46:01 <pounce> does that mean that one must update the interrupt descriptor table on a context switch?
20:46:50 <doug16k> return quickly? no. get interrupts reenabled quickly? yes. switching to a ready thread will get interrupts enabled soon
20:47:39 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
20:48:05 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
20:48:16 <pounce> ready thread?
20:48:27 <doug16k> thread that is ready to run - not suspended
20:48:34 --- join: king_idiot (~bodhi64@17.206.252.27.dyn.cust.vf.net.nz) joined #osdev
20:48:57 <doug16k> when "nothing" is ready to run, the idle thread will be
20:49:24 <doug16k> it sits in infinite hlt loop
20:50:02 <pounce> ah! so you're not advocating for enabling interrupts in the pf-handler, but switching to a new thread with a different kernel stack?
20:50:15 <doug16k> yes
20:50:21 <pounce> got it :)
20:51:34 <pounce> I... have been writing my scheduler to work by switching to a new thread on the iretq on the end of a ISR
20:51:56 <pounce> That really wouldn't work in a lot of circumstances, it seems like
20:52:15 <doug16k> you can't do it there, you need to switch before you restore context
20:52:24 --- quit: caen23 (Ping timeout: 255 seconds)
20:52:56 <doug16k> I made it so I pass the outgoing stack's stack pointer to the interrupt dispatcher, and the interrupt dispatcher returns the new stack pointer (which may be the same stack)
20:53:13 <doug16k> after the dispatcher returns it mov rax to rsp and restores that context
20:53:39 <pounce> and the context info is stored on the kernel stack?
20:54:10 <doug16k> if the interrupt dispatcher wanted to switch stacks then it stored the current thread's stack pointer in the thread info structure of the outgoing thread
20:54:21 <doug16k> er, the function it dispatched to
20:55:19 <doug16k> I made it so I can just return thread_schedule(ctx); (which is isr_context_t *thread_schedule(isr_context_t *outgoing_ctx)) in any interrupt handler and it will reschedule
20:55:49 <doug16k> thread_schedule gets cur_thread from the cpu_info_t at %gs:0
20:55:56 <doug16k> and updates it on the way out
20:56:52 <doug16k> isr_context_t * is the essentially the stack pointer that I switch to before restoring context and iretq
20:57:28 <pounce> ok. but what if this is, as you said, already in an interrupt handler
20:57:54 <pounce> like you had a blocked PF, how would you switch? (because the iretq won't be run until the PF returns)
20:59:08 <doug16k> it will raise another interrupt which saves the context in the page fault. when it switches back to that thread later it will restore context into the page fault code that yielded, and then return back to the page faulting code
21:00:34 <doug16k> when it yields it makes that thread get suspended. when the disk I/O or whatever finishes, it will make that thread ready
21:00:36 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
21:01:01 <doug16k> eventually it will switch back to the thread that blocked on disk I/O, continue the page fault handling code, and return back to the code that faulted
21:02:01 <pounce> (assuming all interrupts use the same kernel stack) I thought the new interrupt would overwrite the PF's stack when the CPU switches to it
21:02:28 <doug16k> "eventually" is likely to be soon, because disk I/O completion should ask for it to reschedule, likely continuing the blocked code soon
21:02:34 <pounce> Unless one uses a separate stack for the yield interrupt
21:02:49 --- quit: quc (Ping timeout: 240 seconds)
21:03:26 <doug16k> it wouldn't have to be separate
21:03:53 <pounce> doesn't the CPU always start at the same address when servicing an interrupt?
21:04:04 <doug16k> no
21:04:26 <doug16k> if it is already in kernel mode it will continue using the same stack, unless you do something to force it to do otherwise
21:04:55 <pounce> oh that's nice
21:05:29 --- quit: caen23 (Ping timeout: 256 seconds)
21:05:38 <doug16k> let's say that a page fault happened, the stack will contain <faulting code's context> <some local variables in interrupt handling>
21:06:01 <doug16k> then it had to yield: <faulting code's context> <some local variables in interrupt handling> <page fault code context>
21:06:28 <doug16k> that thread blocks for while, eventually disk I/O unblocks that thread, so it restores context into the page fault handler: <faulting code's context> <some local variables in interrupt handling>
21:06:43 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:06:47 <doug16k> then the page fault code returns: <faulting code's context>
21:06:58 <doug16k> then the isr restores context: ...empty...
21:08:53 <doug16k> the worst case in my kernel is two contexts on the stack, code originally interrupted, and possibly kernel context that yielded
21:09:46 <doug16k> when it yields it switches to another thread and therefore another stack
21:10:08 <pounce> ok so I would schedule like this: `stack: <old yield frame>` then I run `switch_stacks()` to `stack: <new yield frame>` and return normally
21:10:13 <doug16k> most interrupt handlers don't yield
21:10:15 --- join: quc (~quc@host-89-230-173-123.dynamic.mm.pl) joined #osdev
21:10:47 <doug16k> run switch stacks? why not return the new stack pointer?
21:11:03 <pounce> but then when would I switch stack pointers?
21:11:12 <doug16k> right after it returns
21:11:28 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:11:52 <doug16k> https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/cpu/isr.S#L265
21:11:54 <bslsk05> github.com: dgos/isr.S at master · doug65536/dgos · GitHub
21:12:59 --- join: SwiftMatt (~Objective@2601:282:4300:3e:9932:809a:5202:f95a) joined #osdev
21:14:40 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
21:14:53 <pounce> got it
21:16:05 --- join: ipsumonium (~ipsumoniu@184.75.214.83) joined #osdev
21:16:26 <pounce> what does an ISR look like in your OS? (just to compare arguments and such)
21:16:49 --- quit: quc (Ping timeout: 256 seconds)
21:16:59 * geist takes the ISR and throws it on the ground
21:17:18 <doug16k> https://github.com/doug65536/dgos/blob/master/kernel/device/nvme.cc#L973
21:17:21 <bslsk05> github.com: dgos/nvme.cc at master · doug65536/dgos · GitHub
21:18:28 --- quit: Barrett (Remote host closed the connection)
21:19:08 <pounce> this helps me so much! Thank you
21:19:18 --- quit: caen23 (Ping timeout: 248 seconds)
21:22:23 <doug16k> pounce, any isr can get all the details from the ctx parameter: https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/cpu/idt.cc#L527
21:22:26 <bslsk05> github.com: dgos/idt.cc at master · doug65536/dgos · GitHub
21:22:29 <doug16k> useful for exception handlers
21:22:53 <doug16k> normally the isr doesn't care and can blindly just return the passed ctx
21:23:25 <doug16k> I pass the interrupt number in a register (that first parameter) but you can dig it out of ctx too
21:24:23 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
21:25:05 --- quit: magnificrab (Remote host closed the connection)
21:25:43 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
21:25:50 <doug16k> devices can have a range of IRQs which narrows down which things you touch in the device. for example, an AHCI driver might have 8 IRQs and it tells you which ports might need servicing, so you don't have to pound through every port checking for a completion
21:26:00 <doug16k> which port*
21:26:09 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:26:32 <doug16k> that's why it is important to pass the interrupt number through
21:26:41 <doug16k> they'd all be calling the same ISR
21:27:40 --- part: ipsumonium left #osdev
21:27:49 <doug16k> also, there might be 3 AHCI controllers all calling that same ISR - you need to quickly determine which controller caused the IRQ
21:28:58 --- quit: caen23 (Ping timeout: 256 seconds)
21:32:32 --- join: SwiftMatt (~Objective@2601:282:4300:3e:9932:809a:5202:f95a) joined #osdev
21:36:11 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
21:38:17 --- join: jjuran (~jjuran@c-73-132-80-121.hsd1.md.comcast.net) joined #osdev
21:39:55 <doug16k> geist, lol
21:40:37 --- quit: caen23 (Ping timeout: 256 seconds)
21:43:58 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
21:44:13 <doug16k> I should add a meltdown workaround soon. I'm not particularly motivated because my main machine is an unaffected AMD CPU that doesn't have PCID
21:44:49 <doug16k> although I guess you need a horrible workaround for intel cpus that don't have PCID
21:45:53 <pounce> bleh, I don't even want to think about patching hardware vulnerabilities yet
21:48:48 --- quit: caen23 (Ping timeout: 256 seconds)
21:58:04 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
22:00:24 <doug16k> why is gcc so afraid to use the registers? https://godbolt.org/g/JzLc5N
22:00:25 <bslsk05> godbolt.org: Compiler Explorer
22:00:50 <doug16k> shrq %cl, (%rdi) then imull $100, (%rdi), %eax? really?
22:02:36 --- quit: caen23 (Ping timeout: 255 seconds)
22:03:44 <doug16k> they need an optimization pass that makes it try to use r8 thru r11 for things that are 64 bit anyway
22:04:26 <doug16k> it won't even cost a REX prefix
22:04:40 <doug16k> since they need one already
22:05:38 <doug16k> and in that pass perhaps try to put 64 bit values that are preserved across calls in r12-r15 and 32 bit ones in rbx/rbp
22:05:50 <doug16k> ebx/ebp*
22:06:23 <doug16k> they seem to have goofy "avoid r8-r15" logic in there
22:06:36 <pounce> doug16k: mail them?
22:07:22 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
22:12:09 --- quit: caen23 (Ping timeout: 276 seconds)
22:17:37 <doug16k> in that code it is constrained to hardwired use of cl for the shift, and eax/edx for the div, and it is trying to keep the parameters in rsi,rdi, so what it did makes some sense. the optimizer doesn't seem to realize that mov reg,reg takes practically zero resources. certainly a lot less than a RMW shift followed by an imul that needs store forwarding to not take forever
22:17:52 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
22:20:16 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:20:24 <doug16k> decode bandwidth will be practically infinite in that code, it is completely branch free. it's likely to have decoded past the whole function and returned by the time it gets to executing that stuff
22:22:33 --- quit: caen23 (Ping timeout: 256 seconds)
22:22:40 --- join: babyflakes (uid171740@gateway/web/irccloud.com/x-dgftpzyxogxhkyxh) joined #osdev
22:27:30 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
22:31:51 --- quit: caen23 (Ping timeout: 255 seconds)
22:37:45 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
22:42:38 --- quit: caen23 (Ping timeout: 256 seconds)
22:45:05 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
22:46:45 --- join: silipwn (~silipwn@unaffiliated/silipwn) joined #osdev
22:46:46 --- quit: silipwn (Remote host closed the connection)
22:49:51 --- quit: caen23 (Ping timeout: 255 seconds)
22:54:32 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
22:59:18 --- quit: caen23 (Ping timeout: 255 seconds)
23:05:38 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
23:10:39 --- quit: caen23 (Ping timeout: 276 seconds)
23:15:19 --- quit: Belxjander (Ping timeout: 240 seconds)
23:16:53 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
23:17:02 --- quit: neakitten (Ping timeout: 260 seconds)
23:18:19 <doug16k> I wonder if windows can BIOS boot from a 16GB FAT32 partition that begins at 2TB-1MB (partition begin LBA = 0xfffff800)
23:18:54 <geist> probably
23:18:59 <geist> LBA48 is the last version right?
23:19:39 <doug16k> yes. it would need to support doing disk reads with a 64 bit LBA and need to use 64 bit arithmetic for calculating the start LBA for a cluster
23:20:07 <doug16k> I'm fixing my bootloader to cover that case
23:20:20 <doug16k> a few places I accidentally truncated LBA to 32 bits
23:21:18 --- join: adminseodwn (~archer@unaffiliated/remcwo9o) joined #osdev
23:21:19 --- quit: caen23 (Ping timeout: 240 seconds)
23:21:28 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:21:39 <doug16k> for a laugh I also adjusted my early bootloader code to work all the way back to an 8088 :D
23:21:48 <doug16k> had to avoid lss and lds :D
23:22:12 <geist> 8080 or gtfo
23:22:27 <doug16k> lol
23:23:06 <geist> thohg they're not directly compatible, i was looking into why the bottom 8 bits of eflags are so weird in x86, and iut turns out they're bit compatible with 8080 (or something like that)
23:23:16 <geist> hence why it has this strange layout and some bits are 0
23:23:17 --- join: SwiftMatt (~Objective@2601:282:4300:3e:9932:809a:5202:f95a) joined #osdev
23:23:45 <doug16k> the "bit 1 stuck at 1" thing always struck me as weird
23:24:14 <doug16k> why?
23:24:23 <geist> yeah i think if you look at 8080 layout it sort of makes sense
23:25:52 <geist> iirc it was a little weirder too, because if you looked at the 8086 manual and the 186 and 286 manual, the unused bits had slightly different definitions
23:26:00 <geist> like 'undefined' or 'will be 0' or 'will be 1'
23:26:10 <geist> and it changed across those. iirc at about 386 they were standardized and haven't changed
23:27:25 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
23:27:29 <geist> and i think aside from iret it almost didn't matter on early 8086s. thinking that pushfl didn't exist then?
23:27:48 <geist> something like that, like the layoiut of the register almost doesn't matter because you have instructions to set the flags yourself
23:30:30 --- join: oaken-source (~oaken-sou@p3E9D2477.dip0.t-ipconnect.de) joined #osdev
23:31:37 <doug16k> 8080 flags are S,Z,-,AC,-,P,-,C and 8086 flags are -,-,-,-,O,D,I,T,S,Z,-,A,-,P,-,C - yeah they match exactly in the low 8 bits
23:32:07 <geist> hmm, weird that 8080 had the gaps too. might have to go back to 8008 then
23:32:45 --- quit: caen23 (Ping timeout: 276 seconds)
23:34:01 <doug16k> wikipedia says 8008 flags are C,P,Z,S
23:34:12 <pounce> probably stupid question, but is the 8086 why the architecture is called x86 today?
23:34:32 <geist> pounce: yep. because they quickly started doing 80186, 80286, 80386, etc
23:34:41 <geist> hence 80x86 and then x86
23:34:42 <pounce> ah cool
23:35:11 <doug16k> they realized they can't trademark a number so the pentium, core, atom, etc nonsense took over
23:35:17 --- quit: oaken-source (Ping timeout: 248 seconds)
23:35:21 <pounce> xD
23:35:26 <geist> yah even 486 was technuically something like axp486
23:36:49 <geist> but i think that didn't even work because then others were making things and calling them 486,so they went full on pentium
23:37:00 <pounce> So I was reading up on the 0xFOOF bug the other day, and the wikipedia page said it's been fixed by operating systems. How would one defend against something like that?
23:37:39 <pounce> Other then, of course, enforcing W^X and checking all executable pages for the offending instruction
23:37:41 <geist> f00f was a weird one. read up on it, the fix is extremely clever
23:37:41 <doug16k> they had a suffix "SX" which initially meant Single-word eXternal bus, then they screwed that up because the 486SX had a 32 bit external bus and no FPU, so it must have meant 486 that SuX
23:38:05 <geist> iirc it was some whacky thing like causing the IDT to cross a page boundary or something
23:39:21 <geist> http://www.rcollins.org/ddj/May98/F00FBug.html seems to be a good description of the problem and the solution
23:39:22 <bslsk05> www.rcollins.org: The Pentium F00F Bug
23:39:24 <geist> its really clever
23:40:02 <pounce> huh, so it is
23:40:07 <pounce> I found the same page
23:40:31 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
23:43:30 <pounce> huh that's /really/ clever
23:43:47 <geist> yeah i'm rereading it now
23:44:34 <doug16k> interesting that it can't do a locked memory access to a write-thru page
23:44:44 <pounce> haha this is why OSDEV is so cool
23:44:58 --- quit: caen23 (Ping timeout: 256 seconds)
23:45:23 <geist> i had thought it had something like misalign the IDT so that it crosses a page boundary right on that particular vector
23:45:29 <geist> but may be that IDTs cant be misaligned
23:47:24 <pounce> and it only happens if the IDT's page is present in the TLB I suppose? 0xf00f is a really weird bug
23:47:35 <pounce> Thanks for the link geist :D
23:48:03 <doug16k> this was back when LOCK was nearly pointless. only the most extreme machine would have more than one CPU
23:48:36 <doug16k> so it is somewhat understandable that LOCK wasn't properly tested
23:49:02 <geist> yah i remember this being a fairly minor controversy
23:49:14 <geist> the only real risk was something like an activex control, which was already a terrible idea
23:49:30 <geist> since you probably weren't running some bigass pentium box with a bunch of random users on it
23:49:43 <geist> if you wanted to run a serious unix machine or something you used some sort of real processor
23:50:37 <geist> fdiv was a much bigger controversy
23:50:50 <geist> mostly because intel messed up their PR and made eveyrone want to replace it
23:51:13 <doug16k> a CPU getting math wrong is a pretty big deal though, lol
23:51:51 <pounce> so is a cpu completely locking up ;)
23:52:47 <doug16k> I remember compilers having workaround crap for the fdiv bug, as if fdiv wasn't already horrible enough
23:53:10 <doug16k> I guess if it is horrible already, adding overhead isn't that bad
23:53:37 <geist> key is that almost no one would have been effected with the fdiv bug. it was extremely minor
23:53:39 --- quit: dbittman (Ping timeout: 276 seconds)
23:53:46 <geist> but enough to be a big deal for scientific calculations and whatnot
23:54:05 <geist> but since intel tried to downplay it and got defensive they turned it into a much bigger problem
23:54:32 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
23:55:01 <doug16k> they obviously didn't have very good testing (then or now). you would think that the most basic unit testing would have exercised every div table lookup entry once
23:55:55 <geist> yeah
23:56:15 <geist> though you'd also have to imagine that the tech of doing full simulations and whatnot would just not have been as good
23:56:31 <geist> but yeah, something like foof should have definitely been caught
23:56:38 <geist> at least run all of the prefixes on everything
23:57:29 <graphitemaster> to be fair, in retrospect all of these problems sound like things that wouldn't ever happen had you "did x". I do a lot of unit testing and every so often we encounter a "heh we should've had a unit test for that".
23:57:38 <doug16k> exactly. #UD test should have exercised every invalid combination of prefixes and operands
23:58:00 <doug16k> yeah, the sort of testing we do now wasn't done much then
23:58:01 <pounce> I have a feeling that https://github.com/xoreaxeaxeax/sandsifter will be used on future CPUs
23:58:02 <bslsk05> xoreaxeaxeax/sandsifter - The x86 processor fuzzer (245 forks/3288 watchers)
23:58:59 <graphitemaster> from what I've herd about cpu fuss testing, it's that it's incredibly easy to do at the description level (and they do it) but at the fabrication level of a final product it's almost never done.
23:59:03 <geist> yeah i should run that again. at the time when it was first pointed out i had trouble running it because of some python library bullshit
23:59:06 <graphitemaster> *fuzz
23:59:09 --- quit: caen23 (Ping timeout: 255 seconds)
23:59:24 <doug16k> geist, I hope you have an utterly ridiculous amount of RAM
23:59:27 <geist> also i dunno precisely where HCF style instructions became a non starter
23:59:40 <doug16k> I ran it, it ends up needing way more than 32GB to process the results
23:59:47 <geist> lots of 8 bit machines, 6800 famously, had HCFs and whatnot, and it just wasnt'a problem
23:59:59 --- log: ended osdev/18.01.13