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

Saturday, 6 January 2018

00:00:00 --- log: started osdev/18.01.06
00:00:03 --- quit: quc (Remote host closed the connection)
00:00:18 --- join: quc (~quc@host-89-230-164-119.dynamic.mm.pl) joined #osdev
00:04:23 --- quit: variable (Quit: Found 1 in /dev/zero)
00:17:08 <doug16k> geist, looks like it rings the completion doorbell on every completion. shouldn't it ring it once after it runs out of completions?
00:21:11 <doug16k> and, if I am reading this right, it takes an IRQ for every single completion
00:21:46 <doug16k> i.e., it processes one completion per IRQ
00:27:04 <doug16k> in my driver, when I get one IRQ, I iterate the queue and process all of the completions, then I ring the doorbell once
00:27:07 --- quit: daniele_athome (Ping timeout: 264 seconds)
00:27:43 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
00:28:29 --- join: xerpi (~xerpi@190.red-88-23-232.staticip.rima-tde.net) joined #osdev
00:29:00 <geist> dunno
00:29:13 <geist> feel free to add a comment to the review
00:29:15 <gamozo> nvme driver!? I've always wanted to look into that
00:29:18 <gamozo> is it an open spec?
00:29:23 <doug16k> yes
00:29:26 <doug16k> gamozo, it's nice
00:30:01 <gamozo> I might write a disk emulator soon, not sure what I want to emulate. Not sure if nvme is worth it compared to IDE PIO
00:30:12 <gamozo> or I might just emulate a NIC and iSCSI or something
00:31:29 <doug16k> gamozo, it's probably easier to implement nvme than ide, and much more efficient
00:31:52 <gamozo> was wondering if that would be the case
00:32:02 <gamozo> modern LBA addressing + DMA is a lot simpler than stateful I/O
00:32:12 <gamozo> but I didn't know if NVME was hugely complicated
00:32:31 <gamozo> wait... is NVME like just directly addressable physical memory for the whole disk?
00:32:38 <gamozo> cause that would be the dream
00:32:45 <doug16k> ide has the guest hammering I/Os and you need a big complex state machine. nvme is a queue of nice commands/completions in a circular buffer with a doorbell for submission and completions
00:32:58 <gamozo> so it's like a NIC?
00:33:14 <gamozo> where can I find the spec?
00:33:17 <geist> yeah kinda, a fancy nic
00:33:19 <doug16k> it's similar yeah, a bit like a toned down USB or like a NIC yeah, with dma descriptors and stuff
00:33:21 <doug16k> intel site
00:33:26 <geist> oh no dont make me LMGTFY!
00:33:45 <gamozo> i thought i googled it before and didn't find anything
00:33:46 <gamozo> but now i did
00:33:51 <gamozo> i must have searched something stupid
00:34:01 <doug16k> wait, sorry, it's a dedicated domain: http://nvmexpress.org/resources/specifications/
00:34:02 <bslsk05> ​nvmexpress.org: Specifications – NVM Express
00:34:12 * doug16k googled that for you
00:34:24 --- nick: ahrs_ -> ahrs
00:34:35 <doug16k> except not using google :P
00:34:38 <gamozo> and how much is the variation between drives on NVME? any special casing you have to do per device/versioning?
00:34:41 <gamozo> did you bing it!?
00:34:42 <gamozo> <3
00:34:47 <gamozo> keepin me in business
00:34:51 <doug16k> duckduckgo
00:34:54 <gamozo> lame
00:35:03 --- quit: hppavilion[1] (Quit: HRII'FHALMA MNAHN'K'YARNAK NGAH NILGH'RI'BTHNKNYTH)
00:35:06 <doug16k> dude, duckduckgo is great for programming stuff, seriously
00:35:12 <gamozo> yeah, i used to use it
00:35:33 <gamozo> then I reformatted or something and didn't have it set as default anymore and I just slowly never used it again
00:35:48 <doug16k> gamozo, not much variation. if you stick to PRPs your driver should work on everything
00:36:17 <doug16k> the newer stuff is for fancy SAN fabric things
00:36:25 <gamozo> yeah
00:36:29 <gamozo> 205 pages for the spec, ezpz
00:36:37 <gamozo> I don't think I've read a spec so short in a long time
00:37:05 <gamozo> nvme being used on non-x86 as well too?
00:37:17 <doug16k> why not?
00:37:27 <gamozo> like I know it _could_, but is it
00:38:09 --- join: Asu (~sdelang@AMarseille-658-1-35-212.w86-219.abo.wanadoo.fr) joined #osdev
00:38:15 <doug16k> it's essentially a PCIe device. M.2 is the physical interface, NVMe is the software interface
00:38:46 --- quit: Belxjander (Ping timeout: 248 seconds)
00:38:55 --- quit: zwliew (Quit: Connection closed for inactivity)
00:39:03 <doug16k> typically PCIe 4x interface
00:40:07 <doug16k> you can submit batches of commands and touch one MMIO doorbell, and each IRQ you can receive multiple completions on multiple queues and touch one MMIO doorbell
00:40:34 <doug16k> it is optimized for efficient virtualization and emulation and requires very little uncached reads/writes
00:40:43 <gamozo> yeah this looks great
00:41:11 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:41:35 <doug16k> correction, one MMIO access per queue
00:41:44 <doug16k> you can easily have per-cpu queues
00:42:02 <doug16k> and if you have pci-x, you can have per cpu irqs
00:42:42 --- join: m3nt4L (~asvos@2a02:587:a019:8300:3285:a9ff:fe8f:665d) joined #osdev
00:43:03 <gamozo> looks pretty simple
00:43:08 <doug16k> and (I think) with multiple MSI you can have per cpu irqs too
00:43:29 <doug16k> when you create a queue you tell it the irq offset
00:43:40 <gamozo> oh sweet, only 3 mandatory commands, read, flush, write
00:43:51 <gamozo> so if I write an emulator I can skip the exotics like write zeros and friends
00:44:04 <gamozo> that's what I like to see on the emulator side, lots of optional things I can just disable
00:44:13 <gamozo> (makes for a lot more checks on the driver writing side though :\)
00:44:28 <doug16k> ya, it's all capabilities. you can have max one command and max one completion queue if you want to go all out simple
00:44:42 <gamozo> yeah, that's what I'm gonna aim for
00:44:48 <doug16k> well, 2 if you count the admin queue
00:45:13 <gamozo> man this looks great, I could add disks to my OS finally
00:45:27 <gamozo> still probably rather would NIC stuff out to a storage server though
00:46:12 <gamozo> this is awesome though... write command, data pointer + LBA + some flags, ezpz
00:46:32 <geist> gamozo: it can be absolutely used on non x86s, though it's practially speaking tied to PCI
00:46:35 --- join: qeos (~qeos@ppp158-255-171-31.pppoe.spdop.ru) joined #osdev
00:46:47 <gamozo> PCI is pretty common on phones these days
00:46:52 <geist> so the device needs pci for it to really show up. dunno if we'll see it in the average smartphone yet
00:46:59 <geist> but you can definitelys ee it on servers and whatnot
00:47:29 <geist> there are generally cheaper and lower power mass storage interfaces for phones. MMC and a new thing called UFS
00:47:30 <gamozo> really no reason to believe NVMe won't be the standard fro the next 10 years so this is probably better supporting than IDE
00:47:42 <gamozo> except that IDE is good fo backwards compat, but I don't really care about that
00:47:44 <geist> well, than IDE< absolutely. IDE is dead a long time ago
00:47:58 <geist> SATA/AHCI at east has a bit more life, but NVMe is clearly the successor
00:48:25 <gamozo> NVMe has the benefit of upgrading when PCIe gets faster
00:48:30 <geist> though it's generally intrinsically tied to flash or nvram. so in as much as hard disks with continue to exist, i suspect SATA and SAS will stick around
00:48:30 <gamozo> which is just a regular thing
00:48:54 <geist> but one *could* implement a NVMe based raid controller i guess that bridges to SATA
00:48:59 <gamozo> I wouldn't be surprised if people started doing raid... yep
00:49:05 --- quit: m3nt4L (Quit: Leaving)
00:49:50 <gamozo> that being said, why wouldn't NVMe just expose the whole disk over pmem?
00:49:59 <gamozo> address space worries? 32-bit compat? some other reason?
00:52:28 <doug16k> gamozo, what, all uncached reads/writes? it's better to DMA to/from RAM
00:53:24 <doug16k> GPUs can be accessed with direct reads writes. even they use DMA
00:54:02 <gamozo> ah, makes sense
00:54:16 <gamozo> I'm guessing that NVMe is snooping then?
00:54:22 <gamozo> or is it up to you to flush things out
00:54:40 <doug16k> you put commands in regular system ram and ring a doorbell to issue commands
00:54:48 <doug16k> it dmas the commands out of ram
00:55:01 <doug16k> when it completes them, it dmas the completions into ram and irqs you
00:55:19 <doug16k> you setup circular buffers for each queue and write the mmios to tell it where they are
00:55:31 <doug16k> it uses a phase bit for completions similarly to usb
00:55:45 <doug16k> each time the circular buffer wraps around, the phase bit toggles
00:55:57 <doug16k> you read completions until the phase bit is wrong on the next command
00:56:16 <doug16k> each completion tells you how far along the submission queue it is, so you can advance the submission queue head
00:57:07 <doug16k> you read completions until the phase bit is wrong on the next completion*
00:57:08 <gamozo> I haven't done USB :\
00:57:19 <gamozo> but it does sound identicael to 10gbit nics with rings and multiple queues
00:57:43 <doug16k> yeah, usually the same idea
00:57:46 <gamozo> my NIC that I support mainly (intel x540) has an optional snoop mode where you can use WB memory rather than WC
00:58:03 <doug16k> that way allows you to work directly with ram so you don't have to touch MMIO to see where to stop
00:58:10 <gamozo> although I think it's not a benefit, you're better off with WC
00:58:38 <doug16k> mmio reads are horrible - you can't post them to a queue
00:59:12 <doug16k> so the stuff accessed by the critical code paths try hard to only need writes, on good designs
01:00:01 <gamozo> ah
01:00:18 <gamozo> idk why but I've never fully wrapped my head around MMIO and PCIe and such communications and all the memory modes
01:00:29 <gamozo> who getting notified of what and so on and so forth
01:01:34 <gamozo> I guess I understand on the CPU side all the memory modes, but I'm just never confident in how the device is getting that info
01:03:39 <gamozo> I just need to sit down and do some more device work
01:05:22 <doug16k> same as always - although PCIe uses packets, it still emulates the same behavior as PCI (i.e. looking like there is an address bus, a R/W# line, with a 32 bit bus with 4 byte enables, etc) - it just does it with packets that tell the device the address and data value and stuff, for the access.
01:06:03 --- quit: robert_ (Read error: Connection reset by peer)
01:06:20 --- join: robert_ (~hellspawn@24.96.111.33) joined #osdev
01:06:20 --- quit: robert_ (Changing host)
01:06:20 --- join: robert_ (~hellspawn@objectx/robert) joined #osdev
01:06:58 <jjuran> doug16k: I call that “websearching” :-)
01:07:13 <gamozo> so in the case of NVMe, i'm guessing it's the OSes job to make sure descriptors and buffers are flushed to memory (WC/WT/UC or explicit flush), and then you hit an actual MMIO register that is the doorbell?
01:07:15 <doug16k> if you read about PCIe you can see that they wanted it to be trivially easy to upgrade a PCI design to interface PCIe with minimal changes to its bus logic
01:07:16 <doug16k> physically there is obviously a big difference though :)
01:07:44 <doug16k> since the MMIO is uncached, it acts as an implicit memory barrier and is serializing
01:08:06 <doug16k> all memory accesses before the MMIO access are guaranteed to be globally visible before it starts the MMIO access
01:08:06 --- quit: MindlessDrone (Ping timeout: 248 seconds)
01:08:15 <gamozo> not if they're WB though right?
01:08:20 <doug16k> wrong
01:08:23 <gamozo> oh damn
01:08:35 <doug16k> uncached memory access is the ultimate barrier
01:08:46 <doug16k> everything before it is guaranteed to have finished
01:09:42 --- quit: ephemer0l_ (Ping timeout: 248 seconds)
01:10:11 <gamozo> actually I think at some point I knew that
01:10:17 <gamozo> pieces are coming back
01:10:18 --- join: MindlessDrone (~MindlessD@unaffiliated/mindlessdrone) joined #osdev
01:11:51 <doug16k> MMIO is why it is a strong (serializing) barrier, since it wouldn't make sense for the access to occur out of order
01:12:38 <gamozo> how does that make sure the WC writes are flushed to memory beforehand though?
01:13:10 <gamozo> or did we overlap responses and your wrong was not to the WB question
01:13:19 <doug16k> a serializing instruction won't start until everything before it has retired
01:13:20 <gamozo> cause unless UC writes flush all caches, I don't see how that would work
01:13:35 --- quit: Belxjander (Ping timeout: 268 seconds)
01:13:36 <gamozo> right, but the write would just be in cache and not memory that a device could see
01:13:36 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
01:13:40 <gamozo> unless that device is snooping caches
01:13:43 <doug16k> the DMA can read the cache - PCIe is connected to the CPU
01:13:57 <gamozo> ah
01:13:59 <doug16k> ONLY the CPU accesses the RAM, the memory controller is inside the cpu
01:14:40 <gamozo> weird, I wonder what the snooping control on the x540 was for then? cause I know without it set I had issues when using WB memory for my descriptors
01:14:49 <gamozo> perhaps it was a bypass of snooping and went directly to memory? I have no idea
01:15:04 <gamozo> but the manual suggested using WC + no snooping to decrease snooping traffic
01:15:31 <doug16k> WC is worse than WB from a safety standpoint - WC is weakly ordered
01:16:05 <doug16k> WC would make sense if you were writing to a buffer right on the device
01:16:22 <doug16k> it would allow the CPU to coalesce writes very aggressively into bursts
01:16:37 <doug16k> WB can't - it has to guarantee writes are globally visible in program order
01:16:49 <gamozo> https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-x540-datasheet.pdf
01:16:53 <gamozo> section 3.1.4.5.4
01:17:00 <gamozo> No snoop by default on power on of the NIC
01:17:24 <gamozo> looks like the relaxed ordering is what they want
01:17:31 --- quit: robert_ (Read error: Connection reset by peer)
01:17:48 --- join: robert_ (~hellspawn@24.96.111.33) joined #osdev
01:17:48 --- quit: robert_ (Changing host)
01:17:48 --- join: robert_ (~hellspawn@objectx/robert) joined #osdev
01:19:11 <gamozo> " Using no-snoop expedites the DMA from the X540 to the host memory on
01:19:11 <gamozo> the expense of coherency lost between host memory and CPU cache (refer to the
01:19:12 <gamozo> following notes)."
01:19:18 --- quit: MindlessDrone (Ping timeout: 248 seconds)
01:19:18 --- quit: CompanionCube (Ping timeout: 248 seconds)
01:19:25 <gamozo> yeah, it's some weird stuff
01:19:28 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:19:42 --- quit: MrOlsen (Read error: Connection reset by peer)
01:19:49 --- join: MrOlsen (~reddawg@Pub.SpherePBX.com) joined #osdev
01:20:29 --- quit: lucebac (Remote host closed the connection)
01:20:54 --- quit: sham1 (Ping timeout: 248 seconds)
01:21:06 --- quit: mischief_ (Ping timeout: 256 seconds)
01:21:17 --- join: mischief (~none@iota.offblast.org) joined #osdev
01:21:39 <doug16k> no snoop by the device?
01:21:39 <doug16k> how can PCIe snoop at all? it is a point-to-point protocol
01:21:39 --- quit: doug16k (Excess Flood)
01:21:41 --- nick: mischief -> Guest46668
01:21:56 --- join: ebrasca` (~user@host-198.58.elzappero.net) joined #osdev
01:22:06 --- join: doug16k (~dougx@174-138-193-47.cpe.distributel.net) joined #osdev
01:22:20 <gamozo> I have no idea :P
01:22:21 --- join: MindlessDrone (~MindlessD@unaffiliated/mindlessdrone) joined #osdev
01:22:42 --- join: CompanionCube (samis@unaffiliated/drmushroom) joined #osdev
01:22:56 --- quit: ebrasca (Remote host closed the connection)
01:23:02 --- quit: voidah (Ping timeout: 248 seconds)
01:23:12 <doug16k> wouldn't it be great if IRC had some kind of acknowledgement? I have no idea which is the last message that got through :(
01:23:27 <Mutabah> We have logs :)
01:23:30 --- join: lucebac (~lucebac@unaffiliated/lucebac) joined #osdev
01:23:30 <gamozo> I got "how can... point-to-point..."
01:23:33 <gamozo> as the last one
01:24:28 <doug16k> thanks. this got dropped: gamozo, I don't know. I have never heard of enabling non-coherent writes to system ram before
01:24:41 <gamozo> heh, phew
01:24:50 <gamozo> cause this driver has made me question a lot of what I know about computers
01:25:03 <gamozo> and i didn't know if it was something that was unique to this, or something fundamental i should definitely have known
01:25:11 --- join: voidah (~voidah@unaffiliated/voider) joined #osdev
01:25:19 --- join: sham1 (~sham1@212-146-44-37.aboa.net) joined #osdev
01:26:00 <doug16k> in general, PCIe solves the snooping issue, because it's not a shared bus - the cpu doesn't have to listen for writes and all that crap. the pcie device essentially goes through the cpu
01:26:26 <doug16k> ...to get to ram
01:26:59 <gamozo> so effectively I should use WB for everything EXCEPT for MMIO BARs which should be UC?
01:27:00 --- join: gianluca (~user@lugbari/people/gianluca) joined #osdev
01:27:17 <doug16k> busses suck, big time. only one device can access memory at a time? cpu locked out from accessing anything? horrible
01:27:27 <doug16k> you should use WC for video memory
01:27:32 <doug16k> but otherwise, yeah
01:27:53 <gamozo> Okay cool, cause that's what I've been doing
01:27:58 <doug16k> video memory, or when you are accessing memory on a device
01:28:31 <doug16k> yeah if you are writing commands for a USB or AHCI or something to RAM, it is meant to be WB RAM. the serializing MMIO access will sort it all out
01:28:59 <gamozo> does that go for all arches with PCIe? or is that an x86 thing that UC serializes so hard?
01:29:15 <doug16k> can't say for sure about other architectures
01:29:36 <doug16k> on weakly ordered architectures, I'd expect barriers to be required
01:31:26 <doug16k> a store-release might be enough - it should guarantee prior stores are globally visible before it starts the store-release store
01:33:46 <gamozo> speaking of fences, how do you think intel fixed the recent CPU bug? some fences in the syscall microcode?
01:34:03 <doug16k> and if you read MMIO on a weakly ordered architecture, a load-acquire should guarantee no loads after the load-acquire started early speculatively
01:34:14 <gamozo> yeah
01:34:29 <gamozo> probably some exception on alpha, but nobody cares about alpha :p
01:35:26 <_mjg> alpha is predominantly used to scare people
01:35:35 <doug16k> you don't need to do a syscall to do the bad exploit, normal memory access is all you need
01:35:38 <gamozo> they didn't call it beta for a reason
01:36:37 <gamozo> ah, weird, I didn't read into it much
01:37:01 <sdfgsdfg> whats normal memory access ? userland ?
01:37:17 <gamozo> i was too busy not being surprised that hyper threading + lazy task switches + speculative exec + shared page tables has some fundamental issues :P
01:37:20 <doug16k> the trick is to have it speculatively read kernel memory and use the value in an address calculation - if the kernel memory bit was 1, it writes one cache line, if 0, a different line. the cpu speculatively write-allocates the destination into the cache. you then branch before it gets to those instructions, and time which line got brought into the cache
01:37:49 <sdfgsdfg> why do you need an addr calculation
01:37:52 <gamozo> so what was their fix? where is there microcode during those operations that they can change?
01:38:04 <doug16k> sdfgsdfg, that's how you tell what the value was without having to retire the load
01:38:08 <gamozo> it seems all the ops are too primitive to be changed with microcode?
01:38:30 <sdfgsdfg> I mean whats the use for the value
01:39:19 <jjuran> sdfgsdfg: It allows you to read arbitrary system memory.
01:39:36 <doug16k> what makes it work is, when the cpu writes to a place in memory, it reads that whole cache line into the cache
01:39:45 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
01:39:50 <sdfgsdfg> so its not allowed by default ok
01:40:29 <jjuran> Right, you can’t read it by executing an instruction to read it, but this is a timing side channel which allows you to determine what was stored there anyway.
01:40:42 <doug16k> what you do is make sure neither cache line is cached. then you set it up so the cpu can speculate way ahead and do the kernel memory access, and using that value, determine which cache line gets written. before the cpu even gets all the way to that load and store, you branch away. however, the cpu aggressively got way ahead and did that read and address calculation and write
01:41:08 <doug16k> the write brings a line into the cache. you time whether it was fast or slow to access one of those lines, and that tells you a bit of information about what the kernel memory value was
01:42:09 <doug16k> you don't even take a page fault
01:42:33 <gamozo> will be an interesting year because I'm sure this research will set off more things
01:42:40 <gamozo> there's no way there arent dozens of bugs in this class
01:43:24 <gamozo> i've been a big advocate of 2 things A. don't give users high precision timers. B. don't trust normal ring levels for isolation unless you are flushing TLBs and using different page tables for processes and kernels
01:44:00 <jjuran> High-precision timing could be a privileged service, like binding to ports < 1024.
01:44:08 <gamozo> yeah
01:44:20 <gamozo> rdtsc can be disabled to CPL!=0 in hardware
01:44:41 <gamozo> now mitigating against a thread spinning up and counting to a global and having another thread access that is much harder
01:44:48 <doug16k> as graphitemaster pointed out - you can make a precision timer using a thread hammering increment on a variable
01:45:23 <gamozo> depending on the timing that might not be good enough, but for short times it'll be fine
01:45:27 <gamozo> eg. in a single thread quantum
01:45:46 <gamozo> that being said, accessing another cores memory is very expensive
01:45:59 <doug16k> as another person pointed out, you can make it really cheap by making them use two different hyperthreads sharing the same L1
01:46:02 <gamozo> lots of latency there. you probably can make a good timer for a single uarch, but you need to special case it for each uarch
01:46:38 <gamozo> wait i think i have benchmarks for this one
01:47:49 <gamozo> yeah it's about 25 cycles
01:48:03 <gamozo> depending on how often you poll the timer it might throw it off a lot
01:48:12 <gamozo> but if you read it once, do something, read it again, then it should be quite accurate
01:48:12 --- quit: hmmmm (Remote host closed the connection)
01:48:35 <gamozo> the issue is you cant constantly read it because then you are fighting over ownership of the line nonstop and you get a lot of "random" noise into the timer
01:48:41 <doug16k> 25 cycles is more than good enough. a full cache miss is 1000
01:48:44 <doug16k> ish
01:48:51 <gamozo> yeah
01:49:18 <gamozo> so the ultimate solution is that ring levels should be isolated and tagged and not sharing page tables
01:49:20 <bcos> 25 cycles seems high for the "two logical CPUs in same core" case
01:49:22 <gamozo> and almost all of these issues go away
01:49:51 <jjuran> It sure doesn't help that an attacker gets to run code on your box for free.
01:50:09 <gamozo> was 25 for both my piledriver and knights landing benchmarks
01:50:18 <bcos> Ah
01:50:26 <bcos> How much for normal "core i3/5/7"?
01:50:32 <gamozo> nooooooo idea :P
01:50:36 <bcos> :-)
01:50:51 --- quit: sdfgsdfg (Read error: Connection reset by peer)
01:50:57 --- join: sdfgsdf (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
01:51:01 <gamozo> i think I saved the code for this benchmark, so I could try it on my i7 970 and a few xeons
01:51:10 <gamozo> as long as I can get the topo right
01:51:34 <gamozo> that being said, how are you gonna get one thread incrementing a counter whiel another thread is doing an attack on the same core?
01:51:43 --- quit: sdfgsdf (Remote host closed the connection)
01:51:44 <gamozo> sounds like there's more entropy there than the cost of reading another cores L1 cache :P
01:51:55 <bcos> Anyway; would recommend nerfing TSC by a similar amount - e.g. maybe make it take at least 30 cycles (with maybe another 30 cycles of random delay) so that TSC isn't better than the next best alternative
01:52:03 --- join: sdfgsdf (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
01:52:28 <gamozo> intel could add a TSC_MASK MSR or something, where it masks the bottom N bits
01:52:35 <gamozo> allowing the OS to control accuracy for a given task
01:52:59 <gamozo> that way you still have a cheap way to get a monotonic timer without a syscall, but it can be nerfed
01:53:03 <bcos> Masking doesn't work - you want worse accuracy more than you want worse precisions
01:53:21 <gamozo> TSC_JITTER MSR then jeez
01:53:44 <doug16k> the real solution is to not allow speculative loads to supervisor pages when CPL > 0
01:53:50 <gamozo> ^^^^^^
01:53:50 * doug16k waves at AMD engineer
01:53:58 <gamozo> lmfao
01:54:16 <gamozo> is that their fix though? Was intel able to actual do something like that with microcode?
01:54:25 <gamozo> I cant imagine speculation is controllable via microcode?
01:54:35 <gamozo> I guess maybe there are just shittons of internal bits that allow control over things like that
01:54:55 <gamozo> they probably didn't get a perfect solution, they had to pick the smallest hammer they had a bit to change that had the same effect
01:55:50 <Kazinsal> AMD did it properly from the start
01:56:17 <gamozo> I'm sure AMD has similar bugs
01:56:32 <gamozo> not to shit on AMD, but CPUs are hard and multiprocessing and coherence is even harder
01:56:41 <bcos> AMD has the "spectre" vulnerability, but not the "meltdown" one
01:56:57 <bcos> (at least that's what I've heard so far)
01:57:02 <gamozo> yeah
01:58:08 <gamozo> spectre is just a generic speculative issue
01:58:28 --- quit: ziongate (Quit: ZNC 1.6.5+deb1 - http://znc.in)
01:58:39 <gamozo> but i fail to see how it would be a security risk unless you're branch predicting across protection boundries
01:59:16 <doug16k> I don't know what Intel's fix is yet
01:59:18 --- quit: gianluca (Ping timeout: 248 seconds)
01:59:35 <doug16k> all I know is some MSR that disables something about speculation
01:59:41 <bcos> https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf
02:00:04 <bcos> ^ has some details in their "mitigations" section
02:01:12 <gamozo> yeah
02:01:47 <gamozo> ah, we're still so in the infancy of computers :P
02:01:51 * bcos is still considering a "kernel has its own full virtual address space" approach
02:02:14 <doug16k> bcos, thanks
02:02:15 <gamozo> that's my model
02:02:20 <lava> gamozo: you manipulate BPU and BTB into a state where another program will run the ~2-4 instructions that leak the information into a shared memory region and you use flush+reload to read it from that shared memory region
02:02:25 <lava> a shared library for instance
02:02:50 <lava> BPU and BTB work on virtual addresses and apparently processes are widely ignored on that layer
02:03:10 <lava> so you train BPU and BTB such that the branch is taken / the indirect branch goes where you want it to go
02:03:11 <gamozo> yaeh
02:03:53 <gamozo> just disable all caches? ;D
02:04:01 <doug16k> lol
02:04:07 <lava> we already thought about that question
02:04:09 <gamozo> back to the 80s
02:04:25 <gamozo> in my first hypervisor I had the EPT pages accidentally all UC
02:04:30 <gamozo> it took about 45 minutes to boot into linux
02:04:31 <lava> if you would not have L1/L2/L3 cache, would cache attacks still be possible?
02:04:31 <lava> yes
02:04:44 <lava> the DRAM has a row buffer in every bank, which is in fact some sort of cache
02:04:46 <lava> so
02:05:15 <lava> get rid of caches and DRAM.... but then there's other things that allow you to do the same
02:05:27 <gamozo> kernel and userspace just need real isolation
02:05:32 <gamozo> x86 has always had trash isolation
02:05:37 --- join: bcos_ (~bcos@CPE-58-170-120-76.lns3.fli.bigpond.net.au) joined #osdev
02:05:54 <gamozo> VMs should be used for userland apps on hardware that supports VT-x and SVM
02:05:57 <gamozo> VMs cost so little to run
02:06:07 <doug16k> we need a 1000 cycle stall between instructions, and we need to precharge every dram row after each instruction :P
02:06:20 <gamozo> we just need SRAM instead of DRAM
02:06:24 <gamozo> fixes rowhammer issues too
02:06:29 <gamozo> give me 16GiB of SRAM please
02:06:42 --- quit: sdfgsdf (Read error: Connection reset by peer)
02:07:09 <gamozo> has anyone played with those NVRAM sticks? they're apparently getting popular in servers
02:07:36 <lava> using the DRAM row buffer to leak secrets from one VM without network access to another one: https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_pessl.pdf, doing the same over L3 while also going for a 0% error rate https://gruss.cc/files/hello.pdf, doing the DRAM row buffer channel from an unprivileged app in a VM without network access to javascript in a website running in another VM on the same machine: https://gruss.cc/files/fantastictimers
02:07:36 <lava> .pdf
02:07:37 <bslsk05> ​gruss.cc: 406 Not Acceptable
02:07:37 <latentprion> m o n e r o
02:08:22 --- quit: bcos (Ping timeout: 248 seconds)
02:09:19 <gamozo> RISC-V will fix all these right?
02:09:20 <gamozo> RIGHT?
02:10:11 <bcos_> There's only really 3 cases: CPU so crappy it doesn't speculate, CPU speculates, and "future CPU that works around the speculation problems"
02:10:41 <doug16k> I have an idea: software that doesn't attack the kernel
02:10:46 <jjuran> Maybe we need to vet the code before running it.
02:10:52 <gamozo> i have another idea
02:10:53 <jjuran> Yes, that. :-)
02:11:06 <gamozo> maybe not allowing arbitrary code being run every time you click on a website???
02:11:12 <gamozo> just the little things in life though
02:11:18 --- quit: xerpi (Quit: Leaving)
02:11:19 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
02:11:21 <jjuran> Can we set aside a bit in the opcode to be an Evil bit?
02:11:46 <gamozo> bring back jazelle, replace javascript with java, directly execute javascript in hardware isolated
02:12:04 <doug16k> it's like we are solving the problem of people shooting at you by putting on sufficiently protective armour
02:12:08 --- quit: osa1 (Ping timeout: 248 seconds)
02:12:13 <jjuran> gamozo: https://www.jsdr.org/ :-)
02:12:15 <bslsk05> ​www.jsdr.org: JS;DR: JavaScript required; Didn't Read
02:12:34 <doug16k> if we had armour good enough, there would be little need for jails
02:12:35 <gamozo> i just run firefox in interpreter mode
02:12:36 <gamozo> ezpz
02:12:50 <doug16k> armour and powerful weapons
02:12:53 <gamozo> i actually solve almost all my security issues with money
02:13:03 <gamozo> any box i run a browser on that hits the internet i assume is compromised
02:13:12 <gamozo> all the way to the kernel
02:13:15 <jjuran> seems legit
02:13:34 <gamozo> hence why I do all of my research on an offline network
02:13:50 <gamozo> after years of having an offline network and mirroring/downloading anything you come across things aren't bad at all
02:14:04 <gamozo> all your docs are offline, all your code is, all your OSes and their repos are, etc
02:15:14 <gamozo> on the plus side everything has 0 latency as well
02:16:18 <doug16k> wiping out all of the developers sufficiently clever to perform attacks would be another approach
02:16:43 <gamozo> hey :(
02:19:13 <doug16k> a guy I hung around with many years ago is under suspicion for murder! they found pieces of a woman's body at his apartment D:
02:19:37 <gamozo> sounds like a Wisconsin thing
02:19:38 <jjuran> Did he write a filesystem, by any chance?
02:19:41 <gamozo> was it a skin lamp?
02:19:43 --- join: Humble (~hchiramm@2405:204:5020:f96f:65e7:f491:5232:a961) joined #osdev
02:19:44 <doug16k> I think there's no way he did it, but man
02:20:01 <doug16k> jjuran, no filesystem unfortunately
02:20:02 <Kazinsal> Six of my graduating classmates are dead from fentanyl overdose/poisoning
02:20:08 <gamozo> holy shit
02:20:20 <Kazinsal> Yeah, it's really bad here.
02:20:32 <gamozo> hs or uni?
02:20:37 <Kazinsal> High school
02:20:47 <gamozo> damn :(
02:21:11 <Kazinsal> Yeah, I wasn't really friends with any of them -- I was a horrendously awkward person in high school -- but it sucks
02:21:14 <gamozo> i can always tell the drugs that are gonna be killing people like mad cause whatever garbage underground hip hop i'm into is always talking about them
02:21:34 <Kazinsal> Shitty distributors around here are cutting all sorts of depressive/painkiller shit with fentanyl because it's been so easy to get
02:21:40 <gamozo> it was about 2-3 years ago that I started hearing nonstop rap about fentanyl
02:22:01 <Kazinsal> It's not intentional fent use here, usually it's fake heroin or oxy
02:22:15 <gamozo> ugh
02:22:27 <gamozo> oxy was the go to in my high school, but there was a clean supply
02:22:29 <Kazinsal> They even started finding carfentanil in some of the poorer towns in BC
02:22:53 <Kazinsal> Which is like, elephant anaesthetic
02:22:57 --- join: dennis95 (~dennis@p50915D42.dip0.t-ipconnect.de) joined #osdev
02:23:20 --- join: gianluca (~user@lugbari/people/gianluca) joined #osdev
02:23:29 --- join: m_t (~m_t@p5DDA1B84.dip0.t-ipconnect.de) joined #osdev
02:24:15 <Kazinsal> It's weird because I'm from what's mostly just a stoner town so all these people dropping from fentanyl is nuts
02:25:44 <gamozo> what is the supply? stolen pharma or is it all manufactured by random people in their basements?
02:26:53 <doug16k> the worst is junkies getting disability cheque and a prescription, and selling the pills
02:27:28 <doug16k> being a junkie counts as a disability in this bleeding heart moron country
02:28:06 --- quit: gianluca (Ping timeout: 248 seconds)
02:29:52 <doug16k> it frustrates me that the consequences for destroying your life and making asinine choices is $1000+ per month free money
02:30:27 <doug16k> and practically free rent
02:30:56 <jjuran> Wait, really? Do you have to actually use drugs to be eligible?
02:31:17 <doug16k> no, but being a junkie will qualify you
02:31:17 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-nxkipnqujyctwsdp) joined #osdev
02:31:33 <doug16k> for all the really disabled people, take the money, please
02:35:21 --- join: glauxosdever (~alex@ppp-94-65-233-217.home.otenet.gr) joined #osdev
02:35:26 <jjuran> doug16k: You said “cheque”. Which country do you refer to?
02:35:31 <doug16k> canada
02:36:08 <doug16k> they aren't kidding when they say canadians are nice. so nice that they will pay people not to be criminals
02:36:22 <jjuran> Might be a sound application of game theory
02:36:52 <jjuran> We’re not as nice in the US, especially at the moment.
02:40:03 --- quit: quc (Remote host closed the connection)
02:40:15 --- join: quc (~quc@host-89-230-164-119.dynamic.mm.pl) joined #osdev
02:40:40 <Kazinsal> The big thing about Canada is we'll pay people to not die
02:40:50 <Kazinsal> Instead of stealing money from people and then letting them die.
02:41:48 <sdfgsdfg> I love stir fried rice cakes
02:43:47 --- join: gianluca (~user@lugbari/people/gianluca) joined #osdev
02:44:27 <doug16k> I had an idea to completely eliminate munmap TLB shootdown IPIs: on munmap, queue up a shootdown packet, and don't free the physical pages. as each cpu acknowledges the shootdown, increment a count on the packet. when the packet reaches the CPU count, only then free the physical pages
02:45:08 <doug16k> the CPUs would only visit the shootdown queue on context switch
02:45:53 <doug16k> if it is entering the PID of the shootdown (or if the PID is -1 for kernel munmap) then ignore it if PID != the one being switched to, or flush global pages if PID == -1
02:46:10 <doug16k> sound like that would work?
02:47:12 <doug16k> and, for reducing permissions, copy the page(s) to new pages, and map the PTEs to the relocated pages, and do the same deferred physical memory free
02:48:06 <doug16k> this way, if another CPU has stale TLB, it will safely access the old pages or the pages that are bound for deferred free
02:49:41 <doug16k> when my code is doing over a million mmap/munmaps per second it pegs every CPU with shootdown IPIs - I IPI on every munmap
02:50:05 <doug16k> (it's a stress test :)
02:52:48 <doug16k> this is hopefully a fix. sure, it won't be great to be hammering that queue cross-cpu, but it can't be anywhere near as bad as IPI storming the whole machine
02:54:19 <doug16k> I wonder what happens in linux when 16 threads are doing: for (;;) munmap(mmap(0, 65536, PROT_READ | PROT_WRITE, 0, -1, 0), 65536);
02:54:59 <doug16k> do they IPI eachother to death with all-but-self shootdown IPIs?
02:58:31 --- quit: fodil__ (Ping timeout: 252 seconds)
03:01:12 <doug16k> or better, for (;;) munmap(memset(mmap(0, 65536, PROT_READ | PROT_WRITE, 0, -1, 0), 42, 65536), 65536); :D
03:04:24 <doug16k> another idea was to do something like garbage collection, where I have a separate data structure for physical allocations and frees. allocations come from one pool, frees go to the other. when the allocation pool is drained empty, I swap, so the free pool becomes the alloc pool, and vice versa
03:04:54 <doug16k> I'm not crazy about that one because there is 0% chance of a newly allocated page being hot in the cache
03:05:09 <doug16k> but it might be better than ping-pong of the shootdown queue
03:06:18 --- join: ephemer0l_ (~ephemer0l@pentoo/user/ephemer0l) joined #osdev
03:06:30 <doug16k> I would need something to ensure that enough time has passed to guarantee every cpu has context switched at least once since the last swap
03:06:50 <doug16k> oh and flush global pages when I swap
03:07:02 <lava> i think a good step forward would be proper tagging of all caches
03:07:15 <lava> if you'd tag the BTB spectre variant 2 would be impossible
03:07:49 <lava> if you tag the buffers used for the branch decision, variant 1 would become harder
03:18:11 <bcos_> Sigh
03:18:12 <bcos_> https://www.phoronix.com/scan.php?page=news_item&px=AMD-PSP-2018-Vulnerability
03:18:14 <bslsk05> ​www.phoronix.com: AMD PSP Affected By Remote Code Execution Vulnerability - Phoronix
03:19:23 * bcos_ is starting to think that maybe a baseball bat with spikes might be an effective "vulnerability prevention" tool
03:19:31 <lava> :D
03:19:38 <lava> you just need to find the right people then
03:20:16 <lava> but in this case, at least 4 teams of researchers found that independently, makes at least 11 researchers
03:20:52 --- join: gianluca` (~user@host233-189-dynamic.45-213-r.retail.telecomitalia.it) joined #osdev
03:21:58 --- quit: sprocklem (Ping timeout: 248 seconds)
03:22:13 <bcos_> lava: Them's the wrong people - would want to find people working at AMD and Intel that think "hidden CPUs able to do anything they like" is a good idea
03:22:42 <lava> ^^
03:24:08 --- quit: gianluca (Ping timeout: 260 seconds)
03:38:22 --- quit: raphaelsc (Remote host closed the connection)
03:39:02 --- quit: sizeofcat[m] (Quit: idle on matrix for more than 30 days)
03:40:20 --- quit: Pessimist (Remote host closed the connection)
03:42:21 <doug16k> bcos_, they couldn't be bothered to try it on a real processor?
03:42:28 <doug16k> lame
03:44:16 <bcos_> As long as AMD are going to confirm and issue a fix, why bother spending more time on it?
03:45:07 <gamozo> oh no, here come the conspiracy theories
03:45:19 <doug16k> idk, I for one have heard the story of the boy who cried wolf :)
03:47:03 <doug16k> my fTPM is disabled. did their arm emulator tell them whether it still works with it disabled?
03:47:14 <doug16k> lol
03:48:00 <doug16k> I wonder if their arm emulator can mind-read what the asus bios does to it at startup
03:50:08 --- quit: gianluca` (Ping timeout: 256 seconds)
03:56:55 --- join: fujisan (uid4207@gateway/web/irccloud.com/x-lqiboolwyyrbkicq) joined #osdev
03:58:16 --- quit: froggey (Ping timeout: 248 seconds)
04:04:14 <gamozo> TIL my server has an air shroud that I've been running without
04:04:50 <gamozo> my CPU fans were making some annoying vibrations so I removed the fans, but then the chassis fans were incredibly loud
04:04:52 --- join: froggey (~froggey@unaffiliated/froggey) joined #osdev
04:05:03 <gamozo> so I'm getting the air shroud and the correct passive sinks rather than my active ones
04:05:18 <gamozo> hopefully it'll be much quieter, i might get a DB meter to check
04:05:33 <gamozo> otherwise I'm paying $7k for a sound dampening server rack
04:07:40 <bcos_> You can buy disposable ear-plugs for about 10 cents each
04:09:22 --- join: zng (~zng@ool-18ba49be.dyn.optonline.net) joined #osdev
04:10:13 --- quit: darklink (Ping timeout: 260 seconds)
04:15:43 --- join: darklink (~darklink@unaffiliated/darklink) joined #osdev
04:20:50 --- quit: Belxjander (Ping timeout: 240 seconds)
04:21:04 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
04:21:52 --- quit: immibis (Ping timeout: 256 seconds)
04:25:45 --- join: navidr (uid112413@gateway/web/irccloud.com/x-yibrxvalksltpfwm) joined #osdev
04:26:21 --- quit: Humble (Ping timeout: 252 seconds)
04:27:29 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
04:31:20 --- quit: sdfgsdfg (Ping timeout: 248 seconds)
04:35:56 <gamozo> i have a 1000 pack :P
04:36:11 <gamozo> at least without the vibration ear plugs work for the high freq chassis fans
04:36:56 --- join: user10032 (~Thirteen@2a02:c7d:314e:b300:9990:f7a4:572f:859a) joined #osdev
04:37:59 --- join: Humble (~hchiramm@2405:204:5020:f96f:3354:7769:33ce:9659) joined #osdev
04:38:20 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
04:43:50 --- quit: pg12 (Quit: ZNC - http://znc.in)
04:46:22 --- join: pg12 (~pg12@p200300DBFBD342000EC47AFFFE6AAA70.dip0.t-ipconnect.de) joined #osdev
04:52:56 --- quit: Belxjander (Ping timeout: 246 seconds)
04:56:22 --- quit: lucebac (Ping timeout: 248 seconds)
04:58:36 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
05:10:52 --- join: osa1 (~omer@haskell/developer/osa1) joined #osdev
05:17:47 --- join: phil-opp (~phil-opp@HSI-KBW-46-223-194-9.hsi.kabel-badenwuerttemberg.de) joined #osdev
05:22:28 --- quit: aejsmith (Quit: Lost terminal)
05:24:04 --- join: aejsmith (alex@kiwi/developer/xyzzy) joined #osdev
05:26:01 --- join: selfReferentialN (ad4f345d@gateway/web/freenode/ip.173.79.52.93) joined #osdev
05:28:32 --- join: dhoelzer (~dhoelzer@ool-4a5940e5.dyn.optonline.net) joined #osdev
05:28:36 --- quit: Asu (Quit: Konversation terminated!)
05:30:09 --- quit: Belxjander (Ping timeout: 252 seconds)
05:32:01 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
05:32:40 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
05:34:34 --- quit: heat (Ping timeout: 240 seconds)
05:40:59 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
05:42:30 --- nick: ebrasca` -> ebrasca
05:43:03 --- join: lucebac (~lucebac@lucebac.net) joined #osdev
05:43:03 --- quit: lucebac (Changing host)
05:43:03 --- join: lucebac (~lucebac@unaffiliated/lucebac) joined #osdev
05:50:01 --- quit: listenmore (Quit: Konversation terminated!)
05:59:56 --- quit: variable (Quit: Found 1 in /dev/zero)
06:03:06 --- join: Asu (~sdelang@AMarseille-658-1-35-212.w86-219.abo.wanadoo.fr) joined #osdev
06:05:34 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
06:20:07 --- join: vinleod (~vdamewood@unaffiliated/vdamewood) joined #osdev
06:20:50 --- quit: vdamewood (Ping timeout: 240 seconds)
06:22:15 --- join: fodil__ (~fodil@2a01:e35:39c9:20c0:f072:b7e9:cbd:b02f) joined #osdev
06:22:31 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
06:29:38 --- quit: phil-opp (Quit: Leaving)
06:41:13 --- join: mmu_man (~revol@vaf26-2-82-244-111-82.fbx.proxad.net) joined #osdev
06:41:15 --- quit: sdfgsdfg (Ping timeout: 276 seconds)
06:44:36 --- quit: rain1 (Quit: WeeChat 2.0.1)
06:56:24 --- quit: Beato (Ping timeout: 248 seconds)
06:58:33 --- join: Beato (~Beato@unaffiliated/beato) joined #osdev
06:59:47 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
07:00:06 --- quit: darklink (Ping timeout: 248 seconds)
07:01:27 --- quit: Belxjander (Ping timeout: 252 seconds)
07:02:27 --- join: darklink (~darklink@unaffiliated/darklink) joined #osdev
07:02:37 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
07:02:50 --- join: John___ (~John__@79.97.140.214) joined #osdev
07:07:02 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
07:10:57 --- quit: Asu (Quit: Konversation terminated!)
07:11:27 --- join: Asu (~sdelang@AMarseille-658-1-35-212.w86-219.abo.wanadoo.fr) joined #osdev
07:18:58 --- quit: fodil__ (Ping timeout: 255 seconds)
07:19:08 --- join: fodil__ (~fodil@2a01:e35:39c9:20c0:3099:ec12:52e:9928) joined #osdev
07:28:09 --- nick: vinleod -> vdamewood
07:28:33 --- quit: Belxjander (Ping timeout: 260 seconds)
07:29:02 --- quit: fodil__ (Ping timeout: 246 seconds)
07:29:53 --- quit: CheckDavid (Quit: Connection closed for inactivity)
07:34:15 --- join: atrapado_ (~atrapado@unaffiliated/atrapado) joined #osdev
07:35:26 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
07:37:51 --- join: xerpi (~xerpi@190.red-88-23-232.staticip.rima-tde.net) joined #osdev
07:38:48 --- quit: xerpi (Remote host closed the connection)
07:39:07 --- join: xerpi (~xerpi@190.red-88-23-232.staticip.rima-tde.net) joined #osdev
07:40:34 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
07:42:44 --- quit: daniele_athome (Ping timeout: 265 seconds)
07:43:55 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
07:44:59 --- quit: atrapado_ (Quit: Leaving)
07:46:52 --- quit: Pessimist (Remote host closed the connection)
07:51:18 --- quit: John___ (Ping timeout: 260 seconds)
07:54:15 --- quit: Toldierone (Ping timeout: 252 seconds)
08:01:28 --- join: multi_io (~olaf@x4db48092.dyn.telefonica.de) joined #osdev
08:02:03 <glauxosdever> How does ELF deal with RIP-relative addressing of global data (.data, .rodata, .bss) when the displacement/offset is larger than what the immediate can hold?
08:02:46 <heat> glauxosdever: it doesn't
08:03:06 <heat> the linker prints out a relocation error
08:03:17 --- join: _sfiguser (~sfigguser@host194-66-dynamic.116-80-r.retail.telecomitalia.it) joined #osdev
08:03:49 <heat> I'm pretty sure that you're limited to -2GB,+2GB of rip relative addressing
08:04:34 <glauxosdever> That's for x86_64. What about other architectures that have fixed-size instructions and immediates are <= 16-bit?
08:04:38 --- quit: multi_io_ (Ping timeout: 248 seconds)
08:04:54 <glauxosdever> +/- 64KiB would be pretty limiting to work with.
08:05:39 <glauxosdever> Can it make the linker load the offset into a register and do rip+register for addressing, or something like that?
08:05:49 <clever> i think the linker would need to insert trampolines, that have a wider address in them
08:05:50 <heat> depends on the arch
08:06:10 <heat> x86_64 doesn't allow for that, so you're out of luck
08:06:20 <glauxosdever> (When loading has again to be done in parts, e.g. lowest 16-bit, middle lower 16-bit, etc)
08:06:55 * bcos_ would assume compiler is responsible for generating assembly that linker can link (e.g. generating code that loads the value into a register and then uses the register, if the value won't fit in an immediate)
08:07:47 <glauxosdever> Sure, but does ELF allow that (for such architectures)?
08:08:08 <heat> idk
08:08:16 <heat> check the relocation types for something like that
08:08:24 <heat> maybe some arch has something like that
08:09:41 <heat> glauxosdever: you can check your /usr/include/elf.h, but it's not a story the jedi would tell you
08:10:47 <heat> It's a sith legend, elf.h was able to list every relocation type, but not relocate itself. Ironic.
08:12:07 <glauxosdever> Wait, looking at RISC-V currently.
08:13:47 <glauxosdever> In /usr/include/elf.h - they forgot to include Sortix as 0x53. :p
08:13:54 <glauxosdever> </offtopic>
08:14:19 <glauxosdever> Let's look at the relocations now.
08:14:22 <heat> damn nobody understands my dank prequel memes
08:14:23 <sortie> glauxosdever: Please follow the #osdev guidelines. You must have opened any xml tag before you follow it or you risk making the operators mad.
08:14:57 <glauxosdever> sortie: mkay
08:15:32 <sortie> glauxosdever: It doesn't work that way. You can't just simply edit a Wikipedia article and expect reality to honor your change. Except somehow for dozens of Rust projects.
08:16:09 <glauxosdever> < glauxosdever> </offtopic>
08:16:27 <glauxosdever> We are talking about relocations now.
08:16:44 <heat> no we're talking about the lack of dank prequel memes
08:17:48 --- join: tacco\unfoog (~tacco@dslb-188-110-204-223.188.110.pools.vodafone-ip.de) joined #osdev
08:19:53 <_sfiguser> where can i learn writing good C ?
08:20:04 --- quit: quc (Remote host closed the connection)
08:20:09 <_sfiguser> is it a good exercise to learn by reading source code of core linux programs such as coreutils '
08:20:09 <_sfiguser> ?
08:20:12 <heat> _sfiguser: define "Good C"
08:20:14 <_sfiguser> cp / mv / and so on
08:20:16 <heat> HaHa, no
08:20:17 --- join: quc (~quc@host-89-230-164-119.dynamic.mm.pl) joined #osdev
08:20:23 <heat> coreutils is garbage
08:21:15 <heat> linux's code is kinda bad, every core utility and library is most likely also garbage code
08:21:36 <_sfiguser> ok heat can you suggest some good source to read... heat you see... you know what is garbage C, so you could also know what is good C
08:21:57 <glauxosdever> Look at Sortix utils.
08:22:07 <heat> good C kinda depends on your coding style tbf
08:22:20 --- part: ebrasca left #osdev
08:22:25 <glauxosdever> They are some of the cleanest C code I've seen.
08:22:29 <sortie> glauxosdever: Sortix utils are not great. They're OK. But they have lots of issues I would like to fix, sonot the best learning resource.
08:22:32 <heat> if you define good C as readable and safe, there are a lot of good sources
08:22:44 <sortie> But yes, they are mostly readable
08:22:50 <heat> but don't expect linux and pals to be readable(and safe)
08:23:03 <sortie> glauxosdever: Look at BSD is my general recommendation.
08:23:19 <glauxosdever> Will consider that next time.
08:23:19 <sortie> BSD can also be hairy, but normally much better than their Linux counteparts
08:23:38 <sortie> The code might not be as clean, but it is often a lot more correct
08:23:49 <sortie> glauxosdever: I mostly recommend OpenBSD
08:23:58 <sortie> FreeBSD has weird bloat IMO
08:24:16 <heat> <sarcasm> I mostly recommend musl </sarcasm>
08:24:19 <sortie> NetBSD, I'm not so sure about their quality
08:24:33 <sortie> heat: Well. Beats glibc.
08:24:43 <heat> Tbh I'm not so sure of that
08:24:55 <sortie> My favorite part of glibc is how hard it even is to find the right code
08:25:17 <heat> sortie: that's also my favorite part of sortix :P
08:25:40 <sortie> heat: You find it hard to find code in Sortix?
08:25:57 <heat> absolutely
08:26:05 <heat> i.e the kernel
08:26:12 <sortie> I thought I was reasonably well organized outside of the kernel
08:26:16 <sortie> The kernel, that can be improved.
08:26:36 <heat> there are like 2 or 3 memorymanagement.cpp's
08:26:47 <sortie> Well that's for multiple architectures
08:26:52 <sortie> But yes, there's also a shared one
08:27:00 <sortie> I need to redo lots of that paging code
08:28:17 --- quit: xenos1984 (Quit: Leaving.)
08:29:00 <heat> sortie: Your heap code is also all over the place
08:29:17 <sortie> Well that's actually to organize it
08:29:49 <sortie> malloc is in libc/stdlib/malloc.c, free is in libc/stdlib/free.c, realloc is in libc/stdlib/realloc.c. The shared code is in <malloc.h>, libc/include/malloc.h.
08:30:06 <heat> not really since most of the malloc/free core is inside stdlib/ where some other heap code is at malloc/
08:30:11 <heat> really becomes hard to follow things
08:30:31 <sortie> Right, I have some shared code in libc/malloc. I forgot about that.
08:30:46 <sortie> I see what you mean but it's not hard to find
08:30:51 <sortie> It's just split.
08:30:56 <heat> Sure, hard to follow
08:31:05 <sortie> It does static link well
08:31:24 <sortie> You don't pull in any more of the heap code than you actually need
08:31:51 --- join: gdh (~gdh@2605:a601:639:2c00:210a:54d3:7de1:ff2f) joined #osdev
08:31:55 <heat> I also feel like the constant #ifdef __i386__ do this; #elif defined(__x86_64__) do that; also makes things hard to follow
08:32:24 <sortie> heat: I disagree. It's better than splitting the implementations out in more separate files.
08:32:37 <sortie> Whenever I did that in the past, the split felt more or less artificial than designed
08:32:58 <heat> I don't think so, when it's split you don't have to read/skip past irrelevant code
08:34:00 <sortie> Having to skip such rare sections when you don't care is lower than cost of splitting it into another file and then having to read that
08:34:33 <sortie> I agree a bit with you but splitting such stuff meaningfully isn't something I've been doing right in the past, I think this works better in practice
08:34:44 <sortie> You rarely look at such code anyway unless you actually care about the arch difference
08:34:51 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
08:37:13 <heat> sortie: https://gitlab.com/sortix/sortix/blob/master/kernel/signal.cpp is the worst offender
08:37:15 <bslsk05> ​gitlab.com: kernel/signal.cpp · master · sortix / Sortix · GitLab
08:37:51 <sortie> There's a file where almost all of the signal implementation is in a central place
08:38:01 <sortie> Before stuff was too split, now it's all too together?
08:38:12 <heat> yes
08:38:46 <sortie> I honestly expect this kind of ifdeffery in the signal dispatch code
08:39:03 <heat> some things are too split, other things are too together
08:39:12 <sortie> Well
08:39:14 <sortie> Send a patch
08:39:54 <sortie> I like gathering stuff in signal.cpp because I can link it when people want to learn how signals work
08:40:59 <heat> sortie: The kind of "inlining" that you do is a bit hard to follow and is only feasible because there are only 2 archs that are reasonably simple in dispatching signals
08:41:12 <sortie> Yes
08:41:38 <sortie> heat: It's why I don't split stuff out more. I don't know how to make the right split. Once I have an ARM port, I'll know how better to structure the code.
08:42:30 --- join: rain1 (~user@unaffiliated/rain1) joined #osdev
08:49:05 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
08:56:50 --- quit: Shamar (Quit: Lost terminal)
08:56:52 --- quit: xerpi (Quit: Leaving)
08:59:38 --- quit: s0n1cB00m (Remote host closed the connection)
09:00:09 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
09:01:00 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
09:04:47 --- quit: AntiSpamMeta (Remote host closed the connection)
09:04:48 --- quit: s0n1cB00m (Ping timeout: 260 seconds)
09:04:56 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
09:07:48 <__pycache__> what's up osdevers
09:08:56 <variable> __pycache__: I like your ick
09:08:59 <variable> * nick
09:09:33 <__pycache__> i like it too
09:11:33 --- join: tavish (~tavish@unaffiliated/tavish) joined #osdev
09:13:07 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
09:15:46 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
09:18:05 --- join: AntiSpamMeta (asm@AntiSpamMeta/.) joined #osdev
09:19:44 <mawk> python3 -B
09:19:46 --- quit: Barrett (Client Quit)
09:19:49 <mawk> that kills you __pycache__
09:19:51 --- quit: Belxjander (Ping timeout: 276 seconds)
09:23:20 <__pycache__> mawk: it also kills performance
09:23:22 <__pycache__> :)
09:24:10 <mawk> it's a constant
09:24:32 <__pycache__> ?
09:25:32 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
09:27:37 --- quit: mmu_man (Ping timeout: 265 seconds)
09:35:18 --- quit: tavish (Ping timeout: 248 seconds)
09:35:52 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
09:37:55 --- quit: Belxjander (Ping timeout: 264 seconds)
09:38:26 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-prizprtpevmakdxv) joined #osdev
09:43:49 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
09:43:58 --- quit: Beato (Quit: Bye!)
09:48:38 --- join: martestan (~bee@2001:1530:1000:3127:11df:a344:8c3f:5ccb) joined #osdev
09:50:35 --- join: hmmmm (~sdfgsf@pool-72-79-165-124.sctnpa.east.verizon.net) joined #osdev
09:53:00 --- quit: dhoelzer (Ping timeout: 276 seconds)
09:53:33 --- join: listenmore (~strike@2.27.123.231) joined #osdev
09:55:23 <martestan> some danish high caliber trolls present here, to embarrasse some of their nations big guns, ouh shit man all canadian and danish trolls online!
09:55:38 <rain1> wut
09:55:57 <heat> Mutabah, sortie, geist?
09:57:11 <martestan> one of them allready trying to convince to ban dynamic ip addresses , all of estonia again right, after all heat because you are monkeybrain right?
09:57:25 --- join: Beato (~Beato@unaffiliated/beato) joined #osdev
09:57:31 <heat> oh shit you're that estonian guy
09:57:44 <heat> long time no see
09:57:58 <martestan> heat: monkey call me THE INTELLIGENCE, one of the rare ones to meet here!
09:58:04 <martestan> heat: yeah
09:58:44 <heat> heh you're funny man
09:58:49 <heat> just cut it
09:58:50 <martestan> i just gathered that bjarne stroustrup is from denmark, how to you compare yourself to that man?
09:59:10 <martestan> i have looked up to danish people before, but it seems that you wanna publicly troll
09:59:42 --- quit: brynet (Ping timeout: 255 seconds)
09:59:54 <heat> pls mods help
10:00:43 <martestan> heat: how to you really look at those bir armors of your country banning the intelligence off the channels, being a major troll yourself a pretty clueless one?
10:01:11 <martestan> how to you look at your old time intelligence from denmark, i don't think you manage to get a job again to be fair
10:01:12 <martestan> ?
10:01:25 --- join: raphaelsc (~utroz@179.186.168.22.dynamic.adsl.gvt.net.br) joined #osdev
10:02:58 <martestan> bjarne seeing you make no sense at all , i think he would want to hang himself being embarrassed of the new generation in denmark right?
10:03:08 <martestan> give him something good instead
10:03:18 <heat> sorry but i'm not danish
10:03:49 <heat> you could try looking in other channels but no one here is danish or canadian
10:03:52 --- mode: ChanServ set +o sortie
10:03:56 <sortie> Hi martestan
10:04:05 <sortie> Sorry for the slow reply, I was enjoying family life
10:05:07 --- kick: martestan was kicked by sortie (I'm sorry that you are so miserable. Please stop ruining your life by ruining our life here with spam, death threats, and other crimes. Please make yourself happy by not making yourself unhappy by making yourself interact with me. You can be happy if you stop )
10:06:02 --- join: hmmmmm (~sdfgsf@72.79.170.202) joined #osdev
10:06:37 --- mode: sortie set +b *!*@2001:1530:1000:3127:*
10:07:33 --- join: hmmmmmm (~sdfgsf@pool-72-79-166-51.sctnpa.east.verizon.net) joined #osdev
10:08:56 <sortie> heat: Thanks for the highlight
10:09:11 --- quit: hmmmm (Ping timeout: 265 seconds)
10:09:14 <heat> ;)
10:10:35 --- join: hmmmm (~sdfgsf@72.79.170.209) joined #osdev
10:10:50 --- quit: hmmmmm (Ping timeout: 240 seconds)
10:12:17 --- join: hmmmmm (~sdfgsf@pool-72-79-160-64.sctnpa.east.verizon.net) joined #osdev
10:12:20 --- quit: hmmmmmm (Ping timeout: 240 seconds)
10:14:48 --- join: guest34 (92ffb59a@gateway/web/freenode/ip.146.255.181.154) joined #osdev
10:15:24 <guest34> how can quasimodo live family life, is it actually some women taking dick in the middle of the legs from one of such?
10:15:28 --- quit: hmmmm (Ping timeout: 265 seconds)
10:16:22 <guest34> so you are entirelly bragging that you have gotten another clueless person to deal with in denmark?
10:16:56 <rain1> wut
10:17:01 --- kick: guest34 was kicked by sortie (guest34)
10:17:15 --- mode: sortie set +b *!*@146.255.181.154
10:27:58 --- quit: sprocklem (Ping timeout: 240 seconds)
10:29:47 --- join: Retr0id (~Retr0id@unaffiliated/retr0id) joined #osdev
10:32:52 --- quit: variable (Quit: Found 1 in /dev/zero)
10:33:40 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
10:34:30 --- join: fodil__ (~fodil@2a01:e35:39c9:20c0:84a5:9290:7421:ce88) joined #osdev
10:37:25 --- join: brynet (~brynet@brynet6.biz.tm) joined #osdev
10:38:55 --- quit: s0n1cB00m ()
10:39:11 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
10:49:16 --- quit: s0n1cB00m (Remote host closed the connection)
10:50:06 --- join: wcstok (~Me@c-71-197-192-147.hsd1.wa.comcast.net) joined #osdev
10:53:58 --- quit: sprocklem (Ping timeout: 240 seconds)
10:56:00 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
10:57:16 --- join: xiphias (~xiphffff@unaffiliated/dkingston) joined #osdev
11:05:38 --- join: unixpickle (~alex@2601:645:8103:60b6:44f9:7550:cde4:5f50) joined #osdev
11:12:07 --- quit: caen23 (Ping timeout: 264 seconds)
11:14:38 --- quit: gdh (Quit: Leaving)
11:24:17 --- join: qrf (scum@unaffiliated/yw) joined #osdev
11:24:46 <qrf> I'm trying to understand the Meltdown/Spectre drama and the proposed mitigation. Are any of you really up to speed on that?
11:24:50 <qrf> I just read the Meltdown paper.
11:24:58 <qrf> No the Spectre one so far.
11:25:59 <garit> I did read a bit about it
11:26:19 <garit> both use branch prediction by one way or another, right?
11:26:20 <rain1> ive been trying tot understand it too
11:27:08 <rain1> https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
11:27:09 <bslsk05> ​www.raspberrypi.org: Why Raspberry Pi isn't vulnerable to Spectre or Meltdown - Raspberry Pi
11:27:11 <rain1> having a look at this right now
11:27:52 <bcos_> https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf
11:28:00 <bcos_> ^ best overview I've seen so far
11:28:22 <bcos_> (partly because it includes mitigations and future stuff)
11:30:03 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
11:31:11 <qrf> <garit> both use branch prediction by one way or another, right?
11:31:11 <qrf> Yes
11:31:15 <qrf> Even Intel TSX.
11:31:48 <qrf> I had no idea transactional memory had actually become a part of the mainstream architectures. I was impressed by that. Back then, it was just a research topic at some CS faculty at my university. Nobody took it seriously.
11:32:20 --- quit: alyptik (Ping timeout: 240 seconds)
11:32:26 <bcos_> TSC is just used to avoid page fault and the hassle of dealing with a signal
11:32:29 <bcos_> D'oh
11:32:32 --- join: fodil_ (~fodil@bea13-5-83-156-146-12.fbx.proxad.net) joined #osdev
11:32:33 <bcos_> TSX is just used to avoid page fault and the hassle of dealing with a signal
11:32:48 --- quit: freakazoid0223 (Ping timeout: 265 seconds)
11:33:14 <qrf> The Meltdown paper itself seemed not to sufficiently explain how to extract the 0 or 1 bit from the faulted process, though. I didn't really understand that.
11:33:40 --- quit: fodil__ (Ping timeout: 255 seconds)
11:33:42 <qrf> i.e. how the data is actually leaked.
11:34:08 <bcos_> Assume CPU speculatively executes "movzx rdi,word [kernelAddress]" - CPU ignores page permissions for this (until later)
11:34:08 <rain1> i got the impression they have standard tricks ot check whether something is cached or not, so they chose not to reiterate the details of it
11:35:13 <Brnocrist> well CPU dosn't ignore perms, but just queue the PF and if the prediction is wrong just unwind and don't execute it
11:35:17 <qrf> rain1, you think it's based on timing checks?
11:35:19 <bcos_> Then assume CPU also speculatively executes "shl rdi,8" and "mov rax,[rdi]". Now, the actual values for any of this are discarded (when the CPU finds out that there was a page fault from the first instruction)
11:35:26 <rain1> I think so
11:35:55 <bcos_> ...but CPU still fetches the cache line for that last part; and by figuring out which cache line was fetched you can figure out what value was in RDI and therefore figure out which value was at "kernelAddress"
11:38:37 <qrf> As for the KAISER mitigation propopsed by them... I must admit I don't even know why it's so common to have a designated kernel/system area in process virtual address space.
11:38:44 <qrf> There is something really convenient about it, right?
11:39:05 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
11:39:22 <qrf> It makes some things much easier on context switches, once you're in the kernel then.
11:39:37 <Brnocrist> not easiest, but faster
11:39:39 --- join: alyptik (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
11:40:36 <qrf> Because it enables you to have virtual memory addresses for kernel objects pertaining to the process that cannot overlap with regular user space virtual addresses from the process itself?
11:41:42 <qrf> I don't understand what is made faster by that.
11:42:35 <bcos_> For CPUs without PCID, KAISER trashes all the kernels TLBs when switching from kernel to user-space and ruins performance
11:42:41 <izabera> https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update epic servers run 2x as slow
11:42:45 <bslsk05> ​www.epicgames.com: Epic Services & Stability Update - Forums
11:44:10 <qrf> Brnocrist, what's made faster by it?
11:44:52 <qrf> bcos_, I thought it was way more than that. I thought there was no "system space" in process address space then.
11:45:20 <bcos_> There still has to be a little piece of kernel space mapped in (for system call and interrupt entry points)
11:45:34 --- quit: [Brain] (Ping timeout: 240 seconds)
11:46:44 --- join: cbanu (~cbanu@84.117.206.147) joined #osdev
11:49:44 --- quit: cbanu (Client Quit)
11:50:15 --- quit: kleinweby (Max SendQ exceeded)
11:50:15 <qrf> Right.
11:51:33 --- join: kleinweby (~kleinweby@unaffiliated/kleinweby) joined #osdev
11:54:44 <__pycache__> has anyone here mitigated meltdown in their OS?
11:55:08 <__pycache__> my kernel is not advanced enough for user processes so it's not affected :^)
11:55:15 <heat> I could do it but I don't care that much
11:55:28 <__pycache__> it's not a bug, but only a feature
11:55:35 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
11:55:40 --- join: bm371613 (~bartek@2a02:a317:603f:9800:2216:d8ff:fe87:ef6f) joined #osdev
11:55:41 <heat> it's mostly just implementing KAISER
11:55:50 <Brnocrist> if everything runs in kernel space, you are safe to meltdown!
11:55:56 --- quit: hydraz (Remote host closed the connection)
11:55:56 --- quit: ybden (Quit: ybden)
11:56:01 <heat> aka maintaining a shadow pml4
11:56:51 --- join: ybden (~ybden@coleridge.vehk.de) joined #osdev
11:57:31 <qrf> izabera, I saw that Epic post, yeah.
11:57:58 <qrf> You just need to encrypt all memory, simple!
11:58:06 --- join: fodil__ (~fodil@2a01:e35:39c9:20c0:9c3a:22fc:5277:385d) joined #osdev
11:58:27 --- join: hydraz (hydraz@coleridge.vehk.de) joined #osdev
11:58:27 --- quit: hydraz (Changing host)
11:58:27 --- join: hydraz (hydraz@unaffiliated/demhydraz) joined #osdev
11:58:47 <qrf> Of course it's unrealistic for all userland applications to be rewritten to encrypt their own memory.
11:59:57 <heat> qrf: how do you encrypt the key though?
12:01:49 --- join: dbittman (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
12:02:03 --- quit: s0n1cB00m (Remote host closed the connection)
12:02:33 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
12:05:04 <qrf> I have no idea.
12:06:07 <doug16k> glauxosdever, you don't need rip relative addressing for kernel memory model. what makes the kernel memory model work is the displacement in the addressing mode is sign extended. 0x80000000 -> 00 00 00 80 -> 0xFFFFFFFF80000000
12:06:39 <heat> doug16k: he's not talking about the kernel
12:06:53 <doug16k> and for immediate source operand, all instructions that take a 32 bit immediate sign extend. only a few take a 64 bit immediate
12:06:55 <heat> as far as I'm aware glauxosdever does cpu stuff now
12:07:07 --- quit: s0n1cB00m (Ping timeout: 265 seconds)
12:07:34 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
12:07:47 <glauxosdever> Yep, that's right
12:08:03 <doug16k> ok but what I just pointed out is in effect regardless of memory model. I thought that might have been related to his question earlier
12:08:58 <qrf> I wonder if the Meltdown/Spectre thing will result in architectural changes in CPU design.
12:09:05 <qrf> It's conceivable, isn't it?
12:09:12 <heat> it surely will
12:09:52 <bcos_> Haven't Intel already added some MSRs to nerf branch prediction (via. micro-code update)
12:09:57 <bcos_> ?
12:10:19 <qrf> Realistically, we're best off without an operating system level patch for this in most cases, I suppose. It's just that the browsers need to be hardened against these attacks?
12:10:34 <qrf> bcos_, oh? I wasn't aware.
12:11:02 <heat> qrf, programs too
12:11:15 --- quit: bm371613 (Quit: Konversation terminated!)
12:11:18 <heat> bcos_: Not yet, I don't think so
12:11:26 <heat> check your cpuid though
12:12:14 <Brnocrist> yes, intel already did it
12:12:27 <bcos_> I thought the IBRS, STIBP and IBPB stuff mentioned in "3.2 Branch Target Injection Mitigation" was being rolled out for old CPUs now
12:12:43 <doug16k> I think intel has been intentionally vague about it
12:13:20 <doug16k> "here's a hypothetical solution, be happy now"
12:13:36 <bcos_> I was expecting a press release from Intel saying "Go away, it's freaking holidays dammit"
12:13:38 <bcos_> :-)
12:13:58 <qrf> <heat> qrf, programs too
12:14:03 <qrf> Which ones were you thinking of?
12:14:30 <heat> qrf: Everything
12:14:49 <heat> the exploits aren't limited to browsers
12:14:58 <heat> any program can do them
12:15:06 <bcos_> Erm
12:15:19 <doug16k> I don't think intel is really motivated to actually fix all existing processors. why not allow this to motivate people to buy that new machine?
12:15:36 <bcos_> The first 2 variations ("spectre") only work when a process attacks itself (e.g. javascript attacking the same process it's in)
12:15:46 <bcos_> ..or when kernel attacks itself
12:15:47 <heat> doug16k: Pretty sure they don't want to lose more stock value
12:16:08 --- quit: regreg_ (Ping timeout: 260 seconds)
12:16:34 <Brnocrist> bcos_: that is why the attack surface is not so big, at moment.
12:17:20 * bcos_ nods - "spectre" is mostly limited to cases where you have some sort of "secure" language thing as a sandbox
12:17:39 --- join: hmmmmmm (~sdfgsf@pool-72-79-164-2.sctnpa.east.verizon.net) joined #osdev
12:18:41 <bcos_> (the other example is some strangle interpretted language built into Linux kernel for network packet filtering; where user-space provides "safe byte code" that kernel executes in kernel space)
12:18:54 <bcos_> *strange
12:19:20 <Brnocrist> yes, like eBPF
12:19:31 <bcos_> Ah - yes, that's what Google called it :-)
12:19:41 <doug16k> bcos_, do you subconsciously want to strangle the person that came up with that idea? :D
12:19:44 <Brnocrist> how linux calls it :)
12:19:48 * bcos_ didn't know it existed (and didn't know what Google was talking about)
12:19:50 <bcos_> :-)
12:20:16 <bcos_> doug16k: No, it's not subconsciously... ;-)
12:20:23 <doug16k> lol
12:20:24 <heat> well if you don't JIT it there's no problem, right?
12:20:49 <Brnocrist> if there is not someone that JIT's for you, yes :P
12:21:12 <bcos_> If you do JIT (but there's nothing else in the process' address space) then that's probably fine
12:21:12 --- quit: hmmmmm (Ping timeout: 276 seconds)
12:21:15 <geist> should be no problem, unless you could build a gadget out of non JITted code, but that's pretty unlikely
12:22:03 <bcos_> Main problem with Javascript is that they can't put it in its own process, so it ends up being able to access the parent brower process
12:22:37 <heat> yes, but for something like eBPF?
12:22:43 <geist> though of course 'pretty unlikely' is meaningless here
12:22:54 <geist> so it'd go in the bucket of 'things that might be a problem if someone could figure out how to do it'
12:23:21 <rain1> i cant even think about using linker scripts for a second without turing away
12:23:30 <bcos_> heat: I'm still not sure how much actually uses eBPF - might be able to delete the whole thing with almost nobody noticing
12:24:52 <Brnocrist> tracing/monitoring are mostly based on it
12:25:03 <heat> used by tcpdump at least
12:25:42 <heat> sockets, kprobe, cgroups
12:25:44 <Brnocrist> and all this tools https://github.com/iovisor/bcc
12:25:45 <bslsk05> ​iovisor/bcc - BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more (592 forks/4013 watchers)
12:25:48 <heat> firewalling
12:26:27 --- quit: daniele_athome (Ping timeout: 265 seconds)
12:27:15 <geist> iirc there is some security ssyscall blocking stuff that uses it
12:27:50 <graphitemaster> seccomp
12:27:50 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
12:28:15 --- join: Darmor (~Tom@198-91-187-5.cpe.distributel.net) joined #osdev
12:36:11 <qrf> heat, but the great danger is attacks through JavaScript VMs in browsers, no?
12:36:28 <qrf> Or embedded browsers in email clients etc.
12:36:33 <qrf> Or games.
12:36:45 <qrf> Those are the most common vectors I can think of.
12:36:51 <geist> i puts a crimp on the bytecodebased syscall thing i was thinking of fiddling with on zircon
12:36:52 --- quit: CheckDavid (Quit: Connection closed for inactivity)
12:36:59 <geist> but i think as long as we dont JIT it's still feasiable
12:37:32 <qrf> Downloading malware and running a native binary that Spectre is going to steal what exactly?
12:38:07 <qrf> *that uses Spectre
12:41:38 <heat> passwords
12:41:57 <heat> or take control of your computer by bypassing ASLR
12:42:29 <qrf> heat but Spectre is for the same process only, no?
12:42:44 <qrf> I thought only Meltdown was able to break out of process memory.
12:43:48 <heat> spectre is for different processes
12:44:06 <heat> meltdown is for accessing kernel memory
12:47:16 --- quit: s0n1cB00m (Remote host closed the connection)
12:48:30 --- join: uvgroovy (~uvgroovy@2601:184:4980:e75:d496:f082:6c85:ffa4) joined #osdev
12:55:47 --- join: jrydberg (59fd53b0@gateway/web/freenode/ip.89.253.83.176) joined #osdev
12:56:28 --- quit: Boreeas (Ping timeout: 255 seconds)
13:02:13 <doug16k> does this appear to give a valid approximate ops per second count? http://coliru.stacked-crooked.com/a/6c4b2fe189cc4950
13:02:14 <bslsk05> ​coliru.stacked-crooked.com: Coliru Viewer
13:03:34 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:04:56 --- join: hmmmmm (~sdfgsf@pool-72-79-160-207.sctnpa.east.verizon.net) joined #osdev
13:05:26 --- quit: Belxjander (Ping timeout: 248 seconds)
13:05:35 <geist> there was some chart i saw a while back of the cpu usage on some hosting machine
13:05:42 <geist> as the clients are installing the KPTI fixes
13:06:18 <geist> i ran a little informal benchmark before and after the KPTI patches on my windows box. as expected i saw no real different for games, web browsing, etc
13:06:48 <geist> but a make of a large projet inside the linux-on-windows thing did slow down by a few percentage
13:07:32 --- quit: hmmmmmm (Ping timeout: 265 seconds)
13:08:36 <heat> geist: Windows has KPTI too?
13:08:59 <geist> yeah they already rolled it
13:09:07 <geist> it's part of the january fixes
13:09:19 --- join: mmu_man (~revol@vaf26-2-82-244-111-82.fbx.proxad.net) joined #osdev
13:09:25 <geist> unclear if it's always on, or only if you're an intel cpu, or if you have PCID, etc
13:09:32 <geist> i've only tested it on a skylake machine
13:10:13 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
13:10:34 --- join: immibis (~chatzilla@122-59-200-50.jetstream.xtra.co.nz) joined #osdev
13:11:31 --- join: hmmmmmm (~sdfgsf@pool-72-79-163-8.sctnpa.east.verizon.net) joined #osdev
13:13:46 <nsh> how can i find the physical address of the keyboard input buffer?
13:13:58 <doug16k> linux mmap+munmap 64KB is about 38000 cycles
13:14:07 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-oygxqfdkcujpafjm) joined #osdev
13:14:08 --- quit: hmmmmm (Ping timeout: 246 seconds)
13:14:33 <sortie> nsh: If you mean legacy PS/2 keyboard IO, it doesn't have one. It's all IO ports.
13:16:42 <geist> doug16k: is it actually mapping it?
13:16:56 <geist> there's a POPULATE flag iirc. are you testing with and without that?
13:17:43 <nsh> sortie, i mean, physically in this laptop's ram somewhere there's a buffer that keypresses are mapped to
13:17:44 <nsh> so i assume
13:17:52 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
13:18:03 <sortie> nsh: By a particular operating system? By hardware?
13:18:03 <heat> well you're wrong
13:18:19 <heat> keypresses are kept in a keyboard internal buffer
13:18:25 <rain1> i guess the easiest way would be to make a kernel module to print out the address
13:18:40 <geist> sortie: oh sick burn man
13:18:44 <heat> then they are transmitted by either PS/2 or USB to the driver
13:18:56 <doug16k> geist, I am testing without that deliberately
13:19:12 <sortie> geist: I didn't mean to 'burn', just asking clarifying questions to find the assumptions.
13:19:13 <geist> doug16k: so that should be in theory just setting up some data structures and tearing it down
13:19:19 <sortie> I'm sure something like Linux has such a buffer
13:19:20 <geist> sortie: no i mean he was burning you
13:19:25 <geist> as in 'well youre wrong'
13:19:27 <doug16k> oh sorry that's with memsetting it
13:19:32 <heat> geist: Huh?
13:19:33 <doug16k> so it is probably demand faulting
13:19:40 <heat> I wasn't burning anyone
13:19:43 <geist> oh never mind
13:19:47 <sortie> I wasn't feeling the heat
13:19:56 <geist> i read heat as nsh, and so i was thinking he was just saying you dont know what you're talking about
13:20:00 <geist> disregard.
13:20:30 <sortie> The important thing is that, one day, when a sick burn does occur, geist is there to appropriately recognize it. And that's really what matters.
13:20:37 <doug16k> yes, pre-populate is probably much faster
13:20:46 <geist> i speculatively ran that particular conversation based on a bad branch, so now we can unroll the conversation and dont commit it
13:20:51 <geist> it was a burn mis-predict
13:20:58 <sortie> That's just speculation
13:21:27 <geist> see yall fools is completely in-order
13:21:33 <geist> i'm already running like 10 statements ahead man
13:21:50 <doug16k> with MAP_POPULATE and no memset it's almost 27000 cycles
13:22:03 <geist> please dont use that knowledge to come up with your own SPECTRE attacks on me
13:22:24 <geist> doug16k: ah so you're seeing the delta of not needing to take one or more page faults
13:22:47 <doug16k> yeah
13:22:54 <sortie> I'm sure somebody on memegen did "You speculatively accessed data, but you didn't check the privilege level before accessing privileged data. And that's really the most important part.".gif
13:22:58 --- quit: s0n1cB00m (Ping timeout: 240 seconds)
13:23:36 <geist> nsh: anyway! it depends on the keyboard controller and its interconnect with the rest of the system
13:23:41 <sortie> I need to learn more about those attacks when I have some time. The branch misprediction attacks are worrying.
13:23:47 <doug16k> all your load pipeline is belong to us
13:23:50 * nsh nods
13:23:53 <geist> but the gist is that for both ps2 and usb keyboards, there is a controller on the keyboard that probably has an N keystroke buffe
13:24:17 <geist> and that's transferred to the host cpu roughtly speaking as they happen. that buffer is not memory mapped anywhere
13:24:33 <geist> since both ps2 and usb are a serial link that you transfer the characters over
13:24:57 <geist> then its entirely up to the OS to decide how to buffer the keystrokes. and its predictably quite complex
13:25:09 <nsh> right, thanks
13:25:17 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
13:25:26 <geist> in most cases, especially GUI environments the keystrokes are probably almost immediately consumed by at least one process (X windows, etc) so it can decide where to route it
13:25:45 <geist> then potentially buffered somewhere else, in a message to a process, or a pipe, or whatnot
13:25:55 <geist> same with say mouse or touchpad movements
13:26:30 <geist> on a modern system you wouldn't believe how much code is run every time you press a key or move a mouse. it's fairly astonishing how much goes into that
13:26:36 <geist> tons of context switches, lots f processes, etc
13:27:14 <nsh> is the 16 byte BIOS keyboard buffer not operational after boot time?
13:27:29 <geist> completely gone
13:27:40 <geist> well, if you're running a modern OS other than DOS or something that still uses the BIOS buffer
13:27:41 <nsh> so that's explicitly filled by code in the BIOS i guess
13:27:46 * nsh nods
13:28:09 <clever> that reminds me, apple does some weird crap with their touchpad
13:28:16 <geist> right. that only works as long as you keep the BIOS active and let it control the interrupts and whatnot to the keyboard. but modern protected mode systems (not really even modern actually) just completely cast the BIOS aside
13:28:22 <clever> before the os boots, it runs over usb, and the apple bios supports using it over usb
13:28:38 <clever> after booting, it talks to the OS with i2c, and the OSX OS lacks the usb drivers for the touchpad!
13:28:49 <geist> interesting
13:28:50 <clever> and the i2c lines are routed in an area that makes them prone to water damage
13:28:54 <clever> but the usb lines still work
13:29:09 <nsh> so i guess @lavdos here means a buffer in X windows or the target application itself and not within the kernel itself.. https://twitter.com/lavados/status/949577166966132736
13:29:09 <bslsk05> ​twitter: <lavados> @d3c1ph3red @misc0110 @mlqxyz @StefanMangard @yuvalyarom it's the physical address of the buffer storing the keyboard input
13:29:22 <geist> probably
13:29:24 <nsh> (re: meltdown PoC leaking passwords)
13:29:24 <clever> geist: so the mouse can work on linux, and in the apple bios, but not the main apple os
13:29:25 <nsh> kk
13:29:44 <geist> note that there may still be a buffer in the kernel, for example, that immediately gets consumed
13:29:57 <geist> but if it's a circular buffer and the driver doesn't actually actively wipe out characters as they're read into user space
13:30:09 <geist> it could be that it keeps effectively a log of the last 256 bytes or whatnot typed
13:30:19 <geist> note: should probably do that
13:30:20 --- quit: s0n1cB00m (Ping timeout: 240 seconds)
13:31:03 <rain1> i heard the apple watch and rasberry pi are not vulnerable
13:31:04 <geist> this is one of the many terrible things you can do if you can read kernel space at will
13:31:24 <geist> rain1: yeah they're older dumber cpus
13:31:52 <rain1> is there a new way to design CPUs that avoids this problem?
13:31:54 <geist> unsurprisingly the cortex-a5 and a53 (which are related I believe) are not known to be suceptible to any of these attacks, according to ARM
13:32:01 <geist> proimarily because they're super dumb cpus and dont speculate anything
13:32:09 <geist> rain1: we shall find out
13:32:41 <rain1> i wonder if you could run the kernel on one core and the rest of the system on the others to avoid meltdown
13:32:48 <heat> well AMD processors aren't vulnerable
13:32:57 <geist> cortex-a53 is the fairly low end 64bit arm you see all over the place. kind of the workhorse for at least newer linux-class arm cores that aren't intended to be super powrful
13:33:03 <geist> ie, raspberry pi 3, etc
13:33:20 <geist> heat: to meltdown, they still have the other set of attacks
13:33:34 <doug16k> I was under the impression that RPi3 had an out of order core. it doesn't?
13:33:41 <geist> any reasonably modern core that uses page tables and does some amount of speculation is suseptable to that
13:33:47 <geist> doug16k: nope. it's a cortex-a53
13:33:52 <geist> a53 is a dual issue, in order core
13:34:10 <geist> probably the most popular low end but modern arm core you'll see
13:34:26 <geist> there's technically an a35 64bit core, but i've yet to see that really show up anywhere
13:34:40 <geist> a53 is also generally the LITTLE pair in a big.LITTLE setup
13:35:01 <doug16k> ARM is like a car manufacturer that makes everything from go karts and indy cars D:
13:35:14 <geist> a55 replaces it, and i think it didn't show up on arm's table either as effected, since a55 is just an optimization of a53
13:35:26 <clever> doug16k: our of order core?
13:35:39 <geist> wouldn't quite say indy cars. more like go karts to Prius's
13:35:53 <geist> but they pushing into higher end Mazda Miata territory now
13:35:59 <doug16k> :)
13:36:48 <geist> not really fair, i think an a75 and the ones coming after it are in haswell/skylake territory, if paired with a decent memory subsystem
13:36:52 <geist> which they almost never are
13:37:11 <geist> and clocked up at the same rate that a high end x86 are, which also doesn't really happen
13:37:16 <doug16k> clever, out of order core = can speculatively decode and execute ahead of the current program location, get a head start on independent dependency chains, and deeply overlap execution
13:37:27 <geist> ie, no one really goes out and builds an 85W TDP ARM core and gives it the beans
13:37:32 --- join: unixpickle (~alex@2601:645:8103:60b6:5580:e69c:dcf3:f9f6) joined #osdev
13:37:33 <geist> except the new server cores
13:37:46 <geist> note there's OOO and there's speculative execution
13:38:07 <geist> you generally need to be OOO to get into speculative execution, but OOO doesn't really imply that you go too far ahead
13:38:13 <clever> doug16k: ah, dont know about that area of the rpi cores
13:38:26 <doug16k> you go ahead of the last retired instruction, no matter what, if OOO
13:38:31 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
13:39:04 <geist> but anyway, something like an a53 is pretty much in-order in the sense that it has a fairly classic pipeline
13:39:07 <doug16k> but yeah, speculating through branches and stuff is the next level
13:40:14 <geist> though in the case of a53 it definitely has multiple execution back ends, and they run in parallel, so you can dual issue say a load/store and a multiply or whatnot
13:40:20 --- quit: freakazoid0223_ (Ping timeout: 240 seconds)
13:40:22 <geist> or maybe two alu ops if they're not dependent
13:40:39 <geist> but as soon as a dependency is detected it'd stall one of them and let the other go through
13:40:54 <doug16k> something akin to pentium, where it interlocks early in the pipeline then
13:41:00 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
13:41:03 <geist> more like a P6
13:41:14 <doug16k> P6 is completely out of order speculative core
13:41:15 <geist> except it doesn't go through the 'translate to micro ops' stage
13:41:26 <geist> ehhh, not sure it's that speculative
13:41:38 <geist> well, may be. bad example
13:41:44 <clever> oh, would a memory barrier help with spectre any?
13:41:54 <clever> the kind of thing an OS uses when dealing with MMIO
13:42:00 <geist> trying to find a good pipeline diagram for it, the best i've seen https://www.anandtech.com/show/8718/the-samsung-galaxy-note-4-exynos-review/3
13:42:02 <bslsk05> ​www.anandtech.com: Cortex A53 - Architecture - ARM A53/A57/T760 investigated - Samsung Galaxy Note 4 Exynos Review
13:42:04 <geist> but it's fairly dumb
13:42:56 --- quit: s0n1cB00m (Read error: Connection reset by peer)
13:43:06 <doug16k> I think I get the idea. it's only good for non-dependencies, but for completely independent instructions, it can multi-issue
13:43:17 <geist> basically a53 and then a55 is about as far as you can go and still be in order
13:43:36 <rain1> ahow to write a OS without linker script
13:43:51 <geist> right, and as a result the core size (and thus power usage per MIPS or whatnot is low)
13:43:54 <doug16k> you might say in-order multi-issue
13:43:58 <geist> yah
13:44:21 <geist> rewindong way back to the apple iwatch. it's unclear to me what core is precisely in that
13:44:41 <geist> obviously apple has been building their high end cores, and pairing them with some sort of low end core, whih they may have punched out into the iwatch
13:44:45 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
13:44:56 <geist> but, i think that's an in house design. or they licensed the design from ARM
13:45:18 <geist> thats a newish thing that arm will do now, you can pay more and get a customized variant of one of their cores. QCOM does that for one of their snapdragons now
13:45:43 <geist> they call it their own core, and never refer to the cortex-a* variant itw as derived from, but pretty quickly folks figure out which one its based on
13:46:05 <geist> presumbly it lets you tweak things like size of caches, number of decode units, etc
13:46:57 <geist> i have a cortex-a72 2Ghz machine at home with linux on it (macciatobin board)
13:47:07 <geist> and it's clearly somewhat haswell territory, just runs too slow (2Ghz)
13:47:27 <geist> but if you look at an A72 pipeline, it's a full on OOO, triple decode speculative(?) core
13:48:26 <geist> http://www.tomshardware.com/reviews/arm-cortex-a72-architecture,4424.html has a darn good diagram a litle ways down the page
13:48:29 <bslsk05> ​www.tomshardware.com: ARM Cortex-A72 Architecture Deep Dive - Tom's Hardware
13:48:51 <geist> and it does the full decode-to-microops (though they call them macro ops)
13:50:57 <geist> A73 came shortly afterwards and is a similar design but tuned a bit more for mobile usage. a bit narrower, but more efficient cache/memory subsystem
13:51:12 <geist> which in a smartphone or whatnot is more appropriate
13:51:25 <doug16k> looks good
13:53:12 --- join: xerpi (~xerpi@190.red-88-23-232.staticip.rima-tde.net) joined #osdev
13:53:28 <doug16k> it's a bit ambiguous about where ops wait for their dependencies, dispatch states?
13:53:36 <geist> probably so
13:53:50 <geist> in the retirement queue. it does the work, but can have a kill bit attached to it
13:54:04 <geist> well, for speculative kill
13:54:13 --- quit: xerpi (Remote host closed the connection)
13:54:34 --- join: xerpi (~xerpi@190.red-88-23-232.staticip.rima-tde.net) joined #osdev
13:54:37 <geist> whats also interesting about ARM the company is they clearly hve multiple design teams that are given a fair amount of leeway to do their own thing
13:55:02 <geist> so A72 vs A73 is a pretty good example of two different teams at the same tech level coming at the same problem from different directions
13:55:26 <geist> so internally their designs may vary somewhat, but ed up with a similar thing, just different pros/cons
13:56:10 <geist> the tend to leapfrog each other. at some point i rememberwed which team did what and what was derived from what. Something like A15->A57->A72, and the oter was A12->A17->A73 or whatnot
13:56:15 <geist> and A7->A53->A55
13:58:13 <doug16k> I'm going to try to completely eliminate munmap TLB shootdown later today
13:58:34 <doug16k> er eliminate the IPI I mean
13:59:02 <geist> just tracking which cpu has what mapped is a big win
13:59:12 <geist> and then secondarily caching up all the TLB flushes for a paritcular opeation
13:59:28 <geist> be careful about the unmapping-the-page-table hazard
13:59:29 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
13:59:33 <geist> where you need to TLB flush again
14:00:12 <geist> i just fixed that bug in ARM, and x86 has a similar thing. AMD actually exposes it. there's an EFER bit where you can set it and tell the core that you're willing to deal with inner page table cache flushes yourself and thus get a ilttle performance boost
14:00:23 <geist> EFER.PTC or something or something, look into it
14:00:33 <doug16k> yeah? thanks
14:00:43 --- quit: oaken-source (Ping timeout: 264 seconds)
14:00:54 <geist> otherwise iirc an invlpg is architecturally defined (in AMD world at least) to dump the entire inner page table cache on every iteration
14:00:58 --- join: Asu` (~sdelang@92.184.96.43) joined #osdev
14:01:06 <geist> with that bit set it only dumps the PT cache leading to that particular virtual address
14:01:11 --- quit: Asu (Ping timeout: 265 seconds)
14:01:21 <geist> iirc intel cpus always act in the former way
14:01:36 <doug16k> ah, which explains the chicken bit :D
14:02:02 <geist> ARM exposes all that to software, and you simply have multiple invlpg equivalents. one for what I call 'terminal' flushes vs non terminal
14:02:16 <geist> ie, are you flushing the TLB at the last level of the page table or are you flushing an inner page table modification
14:02:24 <geist> i just added code for this
14:02:46 <geist> https://fuchsia.googlesource.com/zircon/+/master/kernel/arch/arm64/mmu.cpp#443
14:02:48 <bslsk05> ​fuchsia.googlesource.com: kernel/arch/arm64/mmu.cpp - zircon - Git at Google
14:03:02 <geist> see that it uses the 'l' varant of the instruction if it's a terminal flush
14:04:10 --- quit: navidr (Quit: Connection closed for inactivity)
14:04:53 <doug16k> isn't the specific case more common than the global case? if so, I'd swap the order of the last two elses
14:05:32 --- quit: fodil_ (Ping timeout: 265 seconds)
14:05:40 --- quit: fodil__ (Ping timeout: 252 seconds)
14:05:48 <geist> yeah i looked at the compiled logic and decided it wasn't any different
14:06:04 <geist> actually i need to rearrange the master if/else there really
14:06:22 <geist> since the third else clause is the most common
14:06:56 <geist> i think what happens is the compiler ends up inlinging that routine anyway, since the bool arg is always const
14:07:03 <geist> so it just inlines a folded out version of it
14:07:46 <geist> anyway, the lovely thing about ARM in this case is the TLB operation are implicitly global, so you dont have to do any IPIs
14:08:02 <geist> but, they're also completely asynchronous. it's a fire and forget flush, *until* you DSB at the end
14:08:04 --- quit: glauxosdever (Quit: leaving)
14:08:22 --- quit: dennis95 (Quit: Leaving)
14:09:05 <doug16k> yeah, ironic right? arm is weakly ordered but the TLB operation ordering is stronger than x86's TLB ordering, which has an extremely strong memory model :D
14:09:39 <geist> well sort of. you actually have to do stuff like stick in memory arriers to just let the MMU even see it
14:10:27 <geist> note that at say https://fuchsia.googlesource.com/zircon/+/master/kernel/arch/arm64/mmu.cpp#519 where it has updated the page table entry, then memory barriers, then issues the tlb flush (globally)
14:10:30 <bslsk05> ​fuchsia.googlesource.com: kernel/arch/arm64/mmu.cpp - zircon - Git at Google
14:10:41 <geist> that's so that any other cpu that faults at that instant absolutely sees the correc tthing
14:10:53 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
14:11:00 <geist> otherwise it's technically possible for the TLB flush to be broadcast to other cpus while the store of the page table entry itself hasn't been observed
14:11:24 <doug16k> got it
14:11:42 <geist> the MMU itself is treated as an 'external observer' in the inner sharable domain
14:12:04 <geist> so it see sthrough the L1 cache (on modern ARM cores at least) but observes the cpu in the same out of order way that any other cpu does
14:12:25 --- quit: uvgroovy (Remote host closed the connection)
14:12:49 <geist> fairly certain it doesnt even see stuff on the local cpu that hasn't left the store buffer
14:12:57 <geist> ie, not even written back to L1 yet
14:13:39 <geist> but this super beats older ARM cores where the MMU itself couldn't see the L1 cache. you used to have to flush the page table entry out of the L1 cache before the mmu saw it
14:13:56 <geist> also note that arm doesn't generally implement the A and D bit, so the MMU never has to write to the page tables on its own
14:14:15 <geist> but, that's a new feature coming own the pipeline in newer cores. i have to internalize what that actually means
14:14:25 <geist> that's going to be some fun weak memory model shit
14:14:29 <doug16k> you can make that happen on x86 if you want, just always initialize them to 1
14:15:01 <geist> even on x86 i haven't fully internalized the precise ordering of unmapping a thing while another core is accessing/modifying the page
14:15:18 <geist> ie, how do you ensure you dont lose a D bit, which you would generally speaking harvest from the page table entry as you umap it
14:15:47 <doug16k> the A and D are cached in the TLB - you have to IPI if you clear A or D and invlpg in the other processors
14:15:58 <doug16k> otherwise the other cpu will assume they are already set
14:16:12 <geist> yeah it's not about cleaing it. it's about going in an unmapping a page at the exact instant another cpu sets the D bit
14:16:14 <doug16k> if they were set when it loaded it into its TLB
14:16:30 <geist> if you just do a RMW on the page table entry or just blat out 0s to it, cant you overwrite the D bit?
14:16:33 <geist> and thus lose it
14:16:40 <doug16k> if it wasn't set in the other CPUs TLB, it will atomic-or the PTE
14:17:12 <geist> right so in that case does that mean you technically need to atomic and out the present bit, and then go back and check if D got set?
14:18:17 <doug16k> I got you. the race
14:18:30 <geist> at the moment the zircon kernel doesn't harvest D bits, but it will need to eventually
14:18:58 --- join: fodil_ (~fodil@2a01:e35:39c9:20c0:50b4:bae0:cbb8:42a8) joined #osdev
14:18:58 --- join: fodil__ (~fodil@2a01:e35:39c9:20c0:50b4:bae0:cbb8:42a8) joined #osdev
14:19:30 <geist> in which case there are two places where you need to move the D bit from the PTE back to the per-page structure: unmapping it because of a regular unmap, or a specific page table walker that goes through and explicitly unsets the D bit to harvest it
14:19:32 <doug16k> if the other CPU has it D=0 and you clear PTE D bit then IPI the other cpu might dirty it and not set D
14:20:02 --- quit: raphaelsc (Ping timeout: 265 seconds)
14:20:02 <geist> yah i'm not precisely sure how that works. thankfully i have a resident x86 expert that'll figure that out for me
14:20:11 <geist> ARM currently sidesteps it by just not having the A/D bit
14:20:33 <geist> so for the harvest case i'll have to actually go back and flip the page back to read only and then write fault the page to determine when it was modified
14:20:42 <geist> which, all in all, is actually not bad. except for the expense
14:21:23 <geist> there is an A bit in arm, but it acts like a separate present bit: if you touch a page without the A bit set, it generates a special Access Fault, which is assumed to trigger some logic in your code that just goes and sets the A bit
14:21:35 <geist> or if you dont wat to do it, you map every page with the A bit already set
14:21:36 --- join: nicdev (user@2600:3c03::f03c:91ff:fedf:4986) joined #osdev
14:22:17 <geist> so all of that has the nice side effect of your code gets to learn when pages are accessed/dirty as it happens, not as part of needing to go back and harvest it like you do on x86. in some ways that's much cleaner
14:22:23 <doug16k> yeah I should reread that A and D stuff in intel manual ten more times, to be sure, lol
14:23:02 <geist> also read the AMD one, its surprisingly more clear about a lot of the low level TLB/cache bits
14:23:05 <doug16k> on quick thought there is a bad race condition there
14:23:14 <geist> and presumably whatever applies to AMD generally applies to intel
14:23:58 <geist> intel docs tend to describe the feature and let you put 2 and 2 together, AMD docs tend to read more like a narrative, how you're supposed to use it
14:25:12 <_mjg> call me an infidel all you want, i detest intel asm syntax
14:25:32 <doug16k> if you clear it in the PTE then IPI, you could miss a dirtying write if the other CPU has D set in its TLB. if you IPI then clear it in the PTE, then you can still end up with a missed D set, if the other CPU got the IPI just before you wrote the PTE
14:25:58 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
14:26:57 <geist> yah it may be that you have to do some sort of atomic unsetting of the P bit, then ipi it, then afterwards go back and see if the D bit got set
14:27:13 <geist> question there is is the D bit getting set by other cpus treated as an atomic or?
14:27:29 <geist> it almost has to be because there's also the AVL bits that you can presumably fiddle with at any time
14:27:39 <geist> are you supposed to use atomic routines to do that to avoid the D bit getting lost?
14:27:46 <doug16k> I'm pretty sure it is lock RMW or
14:27:54 <doug16k> all of my PTE accesses are atomic
14:28:00 * geist nods
14:28:39 <geist> if thats the case then you might have to or out the present bit, IPI, then go back and harvest D
14:28:43 <geist> ugh. that sounds laaame
14:28:46 <doug16k> mmap semantics are conveniently defined to replace the page on a race. then I just xchg to write
14:29:18 <doug16k> if the old value was present, free it
14:29:26 <doug16k> it = the physical page
14:29:32 --- quit: s0n1cB00m (Remote host closed the connection)
14:29:33 <geist> guessi shoulkd read how ARM intends to implement the A/D bit in hardware and what memory order semantics i'll need to eventually observe
14:30:46 --- join: Guest16 (4d6ff440@gateway/web/cgi-irc/kiwiirc.com/ip.77.111.244.64) joined #osdev
14:31:01 <rain1> https://bpaste.net/show/dad95abf3150 so ive got all these qemus, which one should I make an OS For?
14:31:02 <bslsk05> ​bpaste.net: show at bpaste
14:31:13 --- quit: Guest16 (Remote host closed the connection)
14:31:36 --- join: Guest16 (4d6ff440@gateway/web/cgi-irc/kiwiirc.com/ip.77.111.244.64) joined #osdev
14:31:49 --- quit: Guest16 (Remote host closed the connection)
14:32:12 --- join: raphaelsc (~utroz@187.114.9.239) joined #osdev
14:32:29 <variable> betting pool: how long with discussion of spectre/meltdown happen here?
14:32:39 <rain1> 4 more days
14:32:40 <geist> rain1: well, which arch are you intersted in writing?
14:32:49 <geist> variable: hey we've been ont talking about it for at least an hour
14:32:52 <geist> why yo ugotta mess that up?
14:32:58 <rain1> i guess I am interested in riscv but i dont have it
14:33:08 <variable> geist: :-)
14:33:14 <geist> well, here's the gist: qemu-system-<arch>
14:33:19 <heat> Can't go wrong with x86_64
14:33:22 <geist> so if you're hacking on a PC you'll want i386 or x86_64
14:33:28 <geist> if you want to hack on ARM then use arm or aarch64
14:33:38 <geist> if you wanna hack on 68k then use m68k or whatnot. up to you man
14:36:42 --- part: zhiayang left #osdev
14:38:06 <geist> doug16k: also was just thinking, since the cpu could theoretically asynchronously write back a A/D bit, even if you didn't care and you flushed it with zeros, and then hit the IPI. you absolutely need to wait until the IPI is complete before you return the page table back to the free queue
14:38:17 <geist> otherwise the cpu could come along and set a bit in the middle of a freed page asynchronously
14:38:54 <geist> if you also freed the page table that is after a run of unmaps
14:45:17 --- quit: jrydberg (Ping timeout: 260 seconds)
14:45:41 --- join: bejesus (4d6ff412@gateway/web/freenode/ip.77.111.244.18) joined #osdev
14:47:28 <bejesus> gay lover with irc operator biscuit in front of a danish fucktard, hmm wants to make some training who is faster to ban two million addresses in a row!
14:47:46 <heat> geist, sortie?
14:47:59 <rain1> is this dude typing these manually or is it a word generator bot?
14:48:10 <heat> rain1: Manually I think
14:48:43 <bejesus> rain1 looks to be a markov chain bot...
14:48:50 <rain1> lol
14:48:55 <bejesus> :D:D ahahaaa something new
14:48:57 --- kick: bejesus was kicked by sortie (It's pretty fun how you're so unhappy because you are abuser while we're having a good time being productive)
14:49:09 <heat> thanks mr. sortie
14:49:24 <variable> sortie: ty
14:49:27 --- mode: sortie set +b *!*@gateway/web/freenode/ip.77.111.244.18
14:49:32 --- mode: sortie set +b *!*@77.111.244.18
14:53:04 --- join: proabuser (4d6ff60a@gateway/web/freenode/ip.77.111.246.10) joined #osdev
14:54:18 <jjuran> sortie: ^
14:54:43 --- mode: sortie set +b *!*@77.111.246.10
14:54:47 --- quit: retpoline (Quit: bye)
14:54:49 --- mode: sortie set +b *!*@gateway/web/freenode/ip.77.111.246.10
14:55:10 <doug16k> geist, yes
14:55:50 --- kick: proabuser was kicked by sortie (It's fun to see your psychopathic behavior. Instant, short term gratification. You make yourself unhappy because that's what you do. You could be happy, but you choose not to.)
14:55:57 <sortie> ty jjuran
14:56:01 <jjuran> no prob
14:56:03 --- join: retpoline (~clickjack@185.161.200.10) joined #osdev
14:57:23 <sortie> Protip. If you get banned, don't instantly rejoin from the same subnet revealed by whois.
14:58:46 --- join: seeseemelk (~seeseemel@2a02:a03f:4864:f800:9a7:a596:c315:83d2) joined #osdev
14:58:54 <seeseemelk> I've got a question
14:59:20 <seeseemelk> When doing x86 page mapping, you put in your page directory addresses to your page tables
14:59:35 <seeseemelk> Are these address in your page directory the virtual addresses of your page tables or the physical ones?
14:59:50 <heat> seeseemelk: Obviously, the physical ones
14:59:53 <sortie> It's the physical ones
14:59:56 <seeseemelk> Ok, thanks
15:00:05 --- quit: _sfiguser (Quit: Leaving)
15:00:11 <sortie> It doesn't make sense to store the virtual ones there, since we don't have virtual addresses yet :)
15:00:19 <sortie> See the circular logic?
15:00:31 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
15:00:32 <seeseemelk> Yeah that makes sense
15:00:38 <sortie> :)
15:00:44 <seeseemelk> lol
15:01:45 <doug16k> another way to think of it is, page tables are for linear to physical mapping. the place in the tables is determined by the linear address, the value stored in the page table at that place is the physical address. linear-to-physical
15:05:37 --- quit: s0n1cB00m (Ping timeout: 255 seconds)
15:12:35 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
15:13:35 --- quit: m_t (Quit: Leaving)
15:15:25 --- quit: sortie (Quit: Leaving)
15:15:34 <doug16k> geist, excellent, the nvme dev applied the improvement I suggested immediately :D
15:16:27 --- quit: SN4T14 (Ping timeout: 252 seconds)
15:17:03 --- join: v0rt_ (5238cd4e@gateway/web/freenode/ip.82.56.205.78) joined #osdev
15:17:04 <v0rt_> hi
15:17:16 <variable> hi
15:17:22 <geist> doug16k: yep, that's why i suggested it
15:18:07 --- quit: s0n1cB00m (Ping timeout: 264 seconds)
15:18:24 <v0rt_> I think that this question is annoying you those days. I got how speculative execution works, what I miss is how the kernel address is guessed in meltdown?
15:18:49 --- quit: fodil_ (Ping timeout: 252 seconds)
15:18:49 --- quit: fodil__ (Ping timeout: 252 seconds)
15:19:10 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
15:19:14 <v0rt_> it is calculated the access time on an address, if it is in L1 cache the time is less than if it is not in the cache line, but how this check is performed?
15:20:10 <geist> i think the key is you get the instruction stream to speculatively fetch from an address, then use the result of that to compute another address to do a load/store on
15:20:15 <doug16k> v0rt_, when the cpu speculatively writes the user address after reading the kernel address, the cpu write allocates the line. write allocate means, when you write a line, it brings that whole cache line into the cache
15:20:38 --- quit: sortie (Client Quit)
15:20:44 <doug16k> you just make the value from kernel memory affect which line gets brought in
15:20:48 <geist> then by observing what address it appeared to read/write via cache timing tricks, you can figure out the contents
15:20:51 <geist> exactly
15:21:17 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
15:21:36 <v0rt_> so the kernel address used is the kernel address that we want to leak?
15:21:44 <geist> right
15:22:22 <variable> v0rt_: the important thing is that you really can only guess at the level of roughly a cache line
15:22:29 <variable> not at the level of one byte
15:22:32 <variable> if I understand correctly
15:22:35 <variable> but this is good enough
15:22:47 <v0rt_> so this address doesn't need to be 'called' by CPU, but just wrote in the cache line during speculative exec?
15:22:50 <geist> variable: well, that seems easy though, becuase you could read the value out of a kernel address, then run it through some math, like say mask off most of the bits
15:23:00 <geist> then use that to fiddle with a base address in user space
15:23:10 <geist> then do that again and again, picking out different parts of the word
15:23:23 <variable> geist: true
15:23:42 <geist> v0rt_: yeah, or accessed the cache line by reading it in
15:24:05 <geist> then it discards the result because of the delayed perm check, but by then the cache line has been brought in and there are mechanisms to figure out which one
15:24:19 <v0rt_> so if I am leaking the read syscall address, I should read it from userspace?
15:24:33 <variable> geist: yeah, you could branch on the value of the unknown, and then read to a known address, and see if that vlue is in cache
15:24:34 <bcos_> It's like "movzx rdi, word [kernelAddress]" then "shl rdi,8" then "clfush [rdi]" - can read any byte/word
15:24:48 <doug16k> a simple bit-at-a-time implementation would go like this: speculatively read the kernel address, if it is a 1, write line A, if it is a zero, write line B. before it retires those instructions, branch away so you don't even take a fault. then you measure whether line A or B got brought into the cache
15:25:00 <bcos_> ..although most are doing this in a loop, like "memcpy()"
15:25:50 <geist> yeah, i think there's some additional complexity by needing to prime the L1 cache with the cache line in kernel space
15:25:58 <geist> but presumably that's done with a different loop that causes it to bring it in
15:26:18 --- quit: xerpi (Quit: Leaving)
15:26:31 <geist> since i thkn the whole reason this works is the L1 cache is virtually indexed, so the cpu can read from it prior to consulting the TLB/page tables to make sure you had access to it
15:26:36 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
15:26:47 <bcos_> You'd have a buffer in user-space, make sure it's cached, then "clfush [myBuffer +rdi]" and see what was flushed
15:26:59 <doug16k> you could read more than one bit at a time, but thinking about one bit affecting the destination is the simplest way to picture it
15:27:05 --- quit: gattuso (Remote host closed the connection)
15:27:09 <geist> otherwise if youre speculatively reading from L2 and down, which is physically indexed, you have to at least consult the TLB to figure out which line, and by then you know if it's a supervisor only page
15:27:11 <bcos_> (or the opposite - make sure it's not cached and see what ended up cached)
15:27:14 <v0rt_> this should be the code that performs the leak https://github.com/raphaelsc/Am-I-affected-by-Meltdown/blob/master/assembly_utils.hh#L60
15:27:15 <bslsk05> ​github.com: Am-I-affected-by-Meltdown/assembly_utils.hh at master · raphaelsc/Am-I-affected-by-Meltdown · GitHub
15:28:14 <geist> so a soltuion i could see is to cache the permission bits in the L1 so you can check it synchronously with a load/store
15:28:18 <geist> but i guess intel oesn't do that
15:28:19 --- join: gattuso (~gattuso@pompel.me) joined #osdev
15:28:20 --- join: guest_010101 (~guest@177.189.122.28) joined #osdev
15:28:21 <v0rt_> bcos_: rdi is the kernel address?
15:28:50 <v0rt_> well, the last 8 bit of it
15:28:58 <doug16k> geist, exactly, virtually indexed means, lookup by virtual address at first, and later, make sure the TLB matches the physical tag
15:29:09 <bcos_> v0rt_: RDI would be the byte/word at "kernelAddress"
15:29:21 <v0rt_> ah, the content
15:29:23 <geist> right. that's why that original diagram someone wrote and was asking about the other day put the 'page table' box between L1 and L2
15:29:35 <geist> since from a translation/perm checking point of view it works that way
15:29:40 <bcos_> v0rt_: Think of those instructions like "clfush( myBuffer[(*kernelAddress) * 64] )"
15:30:32 <geist> perhaps that's why AMD machines dont have the problem, if you just cached the U/S bit in the L1 cache line you could probably synchronously check it and nix it before you get started
15:30:57 <geist> but no one knows precisely the layout of the L1 tags on most machines, since that's usually not documented
15:31:40 --- quit: s0n1cB00m (Ping timeout: 256 seconds)
15:31:48 <geist> only machine i know if that's current that i have docs that actually describes the exact format is a Cavium ThunderX. the manual actually precisely describes the contents of the TLB and cache tags, it's neat
15:31:53 <geist> curious now...
15:32:34 <bcos_> 80486 used to have test registers for testing cache and tags - was probably documented
15:32:36 <doug16k> my guess is, AMD has a U/S bit in the tag, so it can see immediately that it is a supervisor page
15:32:53 <geist> bcos_: that's precisely how i know what the cavium tags look like. they have documented test registers for reading them
15:32:55 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
15:33:07 <bcos_> Hrm
15:34:04 <bcos_> doug16k: Intel added a bunch of complex funky junk - protection keys, crypto, ... - would make it hard to have a single "user/supervisor" bit
15:34:14 <doug16k> crypto?
15:34:42 <bcos_> I can't remember what they called it :-(
15:34:50 <geist> actually AMD does too, there's some sort of per page or whatnot crypto stuff
15:34:55 <geist> though that's newer, ryzen
15:35:13 <bcos_> That's different (and sort of at the memory controller/physical address stage)
15:35:43 <bcos_> Intel's let you set aside a range of virtual addresses and give them a key
15:35:52 <doug16k> PKEY
15:36:17 <doug16k> 62:59
15:36:19 <bcos_> ^ was mostly designed for DRM (so hollywood could make sure nobody pirates their trailers..)
15:36:29 <geist> yah plus you might be running in 32bit mode and using all of the rings, etc
15:36:34 <geist> so you'd probably have store all that nonsense too
15:36:58 <doug16k> S = CPL < 3
15:37:04 <geist> from looking at the cavium docs, they absolutely store the EL level the page is readable at in the tag
15:37:24 <geist> so makes that they'd be able to do the nerf there
15:37:37 <bcos_> doug16k: https://en.wikipedia.org/wiki/Software_Guard_Extensions
15:37:38 <bslsk05> ​en.wikipedia.org: Software Guard Extensions - Wikipedia
15:37:39 --- quit: funnel (Ping timeout: 255 seconds)
15:37:49 --- quit: s0n1cB00m (Remote host closed the connection)
15:38:01 --- join: s0n1cB00m (~s0n1cB00m@cpc83309-brig21-2-0-cust565.3-3.cable.virginm.net) joined #osdev
15:38:05 <doug16k> ah, SGX
15:38:10 <geist> doug16k: yeah but if you were running with all three rings you'd need to do the check... oh wait you'd probably do it based on the vaddr, wouldn't need to be stored in the tag
15:38:20 <doug16k> I read about enclaves. haven't touched them with a ten foot pole yet though
15:38:34 <geist> that'd be a separate step (and probably also why segmentation is slower) via a micro op that does the segmentation math and permission check
15:38:47 <fnodeuser> https://www.youtube.com/watch?v=aBQDFQwfX2w
15:38:48 <bslsk05> ​'Watch Silicon Valley Nerds Face Off A Capella (HBO)' by VICE News (00:04:06)
15:40:41 --- quit: Asu` (Read error: Connection reset by peer)
15:41:39 <doug16k> the tag is basically what you expect to be in the TLB. the tag is the logical place to put that if you need to check speculated load permission
15:41:55 --- quit: awang (Ping timeout: 252 seconds)
15:42:03 <v0rt_> ok, maybe I get it, the kernel data is used as index of user-space controlled array
15:42:07 <geist> i guess the complexity there is you'd have to dump L1 cache entries on an invlpg
15:42:12 <v0rt_> so access to this array is calculated
15:42:19 <geist> since you could theoretically change the permission bits of a page
15:42:25 <doug16k> v0rt_, yes
15:42:26 <geist> v0rt_: bingo
15:42:34 <v0rt_> gotcha!
15:42:43 <v0rt_> I missed the index part
15:42:47 <geist> it's one of those conceptually obvious things once you get it and you gotta wonder why no one noticed it until now
15:43:00 <geist> (or maybe they did...)
15:43:28 <doug16k> it is obvious :D
15:43:32 <v0rt_> I read somewhere that shadowbrokers (NSA leaker tools) is seeling a working exploit from NSA leak
15:43:35 <doug16k> like all good ideas
15:43:38 <v0rt_> so probably someone did it before
15:45:07 <doug16k> if I were a conspiracy nutjob I'd think that intel was in on it as a backdoor. thankfully, I'm not crazy (I think)
15:45:38 <rain1> well intel certainly put IME in on purpose
15:45:58 <rain1> and they tried to keep that it was MINIX secret
15:46:22 <doug16k> everything with a vulnerability was put there on purpose. the thing, not necessarily the vulnerability
15:46:54 <heat> rain1: The less they reveal the less attackers know
15:46:56 <bcos_> I think Intel just has a "designed by committee" problem; where they over-complicate everything as much as possible and then wonder why it's too hard to make sure it's secure
15:47:44 <v0rt_> so you think that intel is smarter than they already are? :)
15:47:54 <doug16k> they had to know it was a big risk to speculatively do loads regardless of permission. I give them enough credit to assume that someone thought of this already
15:48:22 <rain1> I think that nobody knew this was a problem
15:48:26 <variable> rain1: ++
15:48:29 --- quit: s0n1cB00m (Remote host closed the connection)
15:48:33 <rain1> its the interaction of two different parts of the CPU
15:48:48 <variable> this feels more like people didn't realize it was an attack vector
15:48:53 <rain1> and I believe that all the CPU designers haev done proofs and verification of the correctness of CPUs
15:48:57 <doug16k> they thought that since it didn't retire, it didn't affect program state, but it did, it affected load latency of write-allocated lines
15:48:58 --- quit: variable (Remote host closed the connection)
15:48:58 <rain1> but only for one 'part' at a time
15:49:03 <doug16k> that's not very obscure to realize
15:49:14 <bcos_> v0rt_: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
15:49:23 <v0rt_> I don't think this is a backdoor, because it is very hard to implement and has not so high risk remotely
15:49:25 <bcos_> ^ mostly, Intel is doing that (but with hardware rather than software)
15:49:37 <rain1> so they would need to extend their proving and verification work to cover: The entire CPU + timing
15:49:52 <rain1> not just logical correctness of each part one by one
15:50:19 <rain1> we also need temporal correctness of the whole system
15:50:23 <doug16k> they didn't quite realize that write allocating a line affects the machine state, even if it doesn't affect program state
15:51:22 <geist> plus a lot of the ASLR defeating stuff relies on the multi level page table, and it taking variable amounts of time to access it
15:51:31 <geist> vs some other MMU designs which are 'flatter'
15:52:09 <geist> but taht goes wayyy back. cpus were using multi level page tables in the 70s. it was one of the first MMU designs outside of just storing the page tables in a flat linear array in a special bank of memory
15:52:37 <geist> so theoreticall something like MIPS or POWERPC is immune to that
15:52:53 <geist> actually wonder if IBM has put out any sort of press release about POWER on any of this
15:53:17 --- quit: Shamar (Quit: Lost terminal)
15:53:27 <doug16k> I'd call it the "write allocate" vulnerability. the speculation is only part of it
15:53:43 --- quit: atk (Quit: Well this is unexpected.)
15:53:45 <geist> https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/ seems ther eare some. will be interesting to see what the linux patches look like
15:53:47 <bslsk05> ​www.ibm.com: Potential Impact on Processors in the POWER family - IBM PSIRT Blog
15:54:57 --- join: atk (~Arch-TK@ircpuzzles/staff/Arch-TK) joined #osdev
15:58:04 <jjuran> I’m guessing there won’t be any Mac OS X patches
15:58:22 <geist> what do you mean?
15:58:35 <jjuran> On PowerPC :-)
15:58:44 <geist> oh hah yesh
15:58:54 <geist> in fact i think they said it'd only be available on high sierra
15:59:07 <jjuran> Wow.
15:59:14 <geist> though i might br wrong
15:59:57 <jjuran> I saw an article which indicated that 10.13 would get an update, but I haven’t seen negative confirmation that earlier versions won't.
15:59:59 <geist> oh i'm wrong. they patched back through 10.11
16:00:14 <geist> actually apparently it rolled out a while back, back in december
16:00:22 <jjuran> ah, nice
16:01:02 <geist> i do know that the 32bit OSX kernel already was running with a full kernel address space swap
16:01:16 <geist> at the time i was curious about it, and it wasmostly because it came from a PPC port, where that's common practice
16:01:52 <geist> basically if you implement an architecture that has ASIDs but no global bit, it's the most efficient and clear way to do it
16:02:00 --- quit: bitch (Read error: Connection reset by peer)
16:02:06 <geist> so i think it was also common and possible on ultrasparc and others as well
16:02:08 --- quit: Tanjoodo (Ping timeout: 246 seconds)
16:02:28 <geist> but conversely if you're using something dumb like x86 it was common practice to keep the kernel mapped, and then the global bit was added to mitigate the expense
16:02:33 <doug16k> nobody used PCID at all on x86 before did they?
16:02:47 <geist> it's still pretty new. effectively haswell+, AMD doesn't implement it
16:03:02 <geist> and it doesn't keep you from doing the TLB shootdown, so iirc it actually sort of makes things worse
16:03:18 <doug16k> I remember reading a thread on the linux kernel mailing list where linus basically said it is worse
16:03:20 <doug16k> yeah
16:03:41 <geist> since now implicitly switching address spaces doesn't dump user space, so i think you have to conceptually TLB shootdown in *all* cpus, in case it did have a cached copy of it with a different PCID set
16:03:42 <doug16k> I looked because I was adding it in my kernel, and it seemed worse
16:03:56 <geist> whereas without it you can assume if any given cpu hasn't mapped it its not active and thus you dont have to TLB shootdown
16:04:26 <geist> ARM solves it by having the broadcast TLB instructions, so you're essentially always shooting donwn on all cpus all the time, by ASID, but it's not expensive
16:04:29 <geist> so doesn't matter
16:05:13 <geist> so essentially PCID is half-assed, only gets you part of the solution you really want, which is what ARM (and other machines) have been doing for a long time
16:05:43 <doug16k> the invpcid instruction is nice. you can flush global pages without taking two vmexits toggling the global enable bit
16:06:13 <geist> yah. confusingly AMD has an invlpga instruction, but i think the A is for what they called ASID, which is actually a VMID
16:08:55 <geist> i suppose you could do some clever thing where if a cpu doesn't currently map a PCID that you're flushing pages on, you write out some sort journal for it to read when it becomes active
16:09:13 <doug16k> yes exactly, you have to shootdown the PCID in every cpu regardless of whether it is running there
16:09:15 <geist> then, when it context switches back to that PCID it can do a series of local invlpgs to deal with it
16:09:30 <geist> or if the list is too long just dump the entire tlb cache for that pcid
16:09:35 <doug16k> that's why it felt worse
16:09:54 <geist> right. that was my conclusion a year or two ago when i read about it. i dont know if there are any more clever solutions since
16:10:21 <geist> really x86 really seriously needs a TLB op broadcast mechanism
16:10:47 <geist> maybe this will force intel to finally deal with it in an upcoming cpu
16:13:28 <Brnocrist> https://github.com/lgeek/spec_poc_arm
16:13:29 <bslsk05> ​lgeek/spec_poc_arm - Dump privileged ARM system registers from usermode using variant 3a of Meltdown (0 forks/0 watchers)
16:14:44 --- quit: v0rt_ (Quit: Page closed)
16:14:54 <geist> yep. that's a fun one
16:15:08 <geist> now i gotta run this one.... i have an a72 machine
16:15:44 <geist> oh wow it runs great!
16:16:54 --- quit: Humble (Ping timeout: 240 seconds)
16:17:55 <geist> even leaks EL2 space, so you can see hypervisor bits
16:18:50 <gamozo> good mornin nerds
16:19:12 --- quit: adam4813 (Quit: Connection closed for inactivity)
16:19:20 <geist> now arguably there's not a lot to leak there in general. the only really intresting one i think is the base addresses for the vector table (which would be pointing off in the trampoline if you implemented KPTI) and stuff like the root page tables
16:20:22 <geist> can probably leak stuffout of ESR and ELR, but i think those can be written to and cleared out by the kernel before switching back
16:22:01 --- join: gdh (~gdh@2605:a601:639:2c00:807:1c74:4fb1:3ce4) joined #osdev
16:25:41 --- join: bitch (hctib@gateway/shell/elitebnc/x-saydqowdulomomfo) joined #osdev
16:27:02 --- quit: user10032 (Quit: Leaving)
16:29:48 <heat> tfw you find out you're running KPTI without even knowing about it
16:30:17 <heat> "30% performance impact" they said
16:32:10 <geist> it's highly load specific
16:32:17 --- quit: xenos1984 (Quit: Leaving.)
16:32:20 <geist> i think in most cases for most normal desktop activity it's probably not noticable
16:32:48 <gamozo> it'd be nice if they gave details on what they changed so you could speculate what to avoid for performance
16:32:54 <doug16k> I saw a "getpid" perf test, that spams calls to getpid. that test shows a huge impact, because it measures just the overhead difference and getpid is practically a noop
16:33:27 <doug16k> or getuid, or something equally nooppy
16:34:02 <heat> that's stupid
16:34:04 <clever> doug16k: https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update
16:34:07 <bslsk05> ​www.epicgames.com: Epic Services & Stability Update - Forums
16:34:10 <clever> doug16k: this service saw a 50% loss in performance
16:34:22 <doug16k> heat, measuring overhead is stupid? ok then
16:34:54 <gamozo> people think intel is gonna suffer due to this, but ultimately people will have to buy 30% more CPU ;P
16:35:50 <heat> doug16k: Measuring overhead is useless as everyone knows it's going to increase substancially
16:35:54 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
16:36:12 <heat> testing real workloads would be better
16:37:58 <heat> gamozo: intel already suffered a lot, lost $11 billion in stock value
16:41:39 <doug16k> heat, measuring it pounding through the syscall layer over and over gives you best case numbers. the whole code path and the related data will be hot in the cache. you could say it gives you a minimum overhead value. in real workloads, it would be worse because not everything will be warmed up so much
16:42:09 --- quit: Barrett (Quit: exit)
16:44:30 --- join: bcos (~bcos@CPE-101-103-141-217.lnse1.way.bigpond.net.au) joined #osdev
16:45:42 --- quit: fujisan (Quit: Connection closed for inactivity)
16:45:46 <gamozo> heat: they've largely recovered
16:45:52 <gamozo> also $11 billion in stock value is an absolute
16:45:54 <gamozo> they're down like 3%
16:45:56 <gamozo> whoop-de-doo
16:46:45 <gamozo> markets are smart enough to know security doesn't matter
16:47:23 --- quit: bcos_ (Ping timeout: 260 seconds)
16:54:42 --- quit: mmu_man (Ping timeout: 265 seconds)
16:55:01 --- join: bcos_ (~bcos@1.123.144.96) joined #osdev
16:57:31 <izabera> isn't 3% like $330m
16:58:19 --- quit: bcos (Ping timeout: 268 seconds)
16:59:18 --- quit: bcos_ (Ping timeout: 252 seconds)
17:01:31 --- join: funnel (~funnel@unaffiliated/espiral) joined #osdev
17:09:30 --- quit: seeseemelk (Quit: Leaving)
17:12:26 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:14:49 --- join: guest_01010101 (~guest@191.193.56.63) joined #osdev
17:15:07 --- quit: guest_010101 (Ping timeout: 265 seconds)
17:15:30 <gamozo> it's recovered since the initial release
17:15:42 <gamozo> also depends when you compare against
17:15:47 <gamozo> they hit record highs in december
17:16:04 --- join: unixpickle (~alex@2601:645:8103:60b6:11c4:7b32:b817:9536) joined #osdev
17:16:06 --- quit: Belxjander (Ping timeout: 248 seconds)
17:16:15 --- quit: unixpickle (Client Quit)
17:21:06 --- join: zwliew (uid161395@gateway/web/irccloud.com/x-vcwloakujkkozhrv) joined #osdev
17:21:10 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
17:29:19 --- join: _Altenius (Altenius@gateway/shell/panicbnc/x-wxhrvjxyienymgys) joined #osdev
17:29:37 --- quit: Altenius (Ping timeout: 255 seconds)
17:40:23 --- quit: huaw (Read error: Connection reset by peer)
17:48:22 --- join: hacku (~hacku@5070A9C0.static.ziggozakelijk.nl) joined #osdev
17:48:58 --- quit: daniele_athome (Ping timeout: 252 seconds)
17:49:21 --- join: huaw (xexexepi@gateway/shell/elitebnc/x-atdfjjwbxfclqtts) joined #osdev
17:50:18 --- join: John___ (~John__@79.97.140.214) joined #osdev
17:51:17 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
17:51:48 --- quit: sortie (Read error: Connection reset by peer)
17:52:12 --- quit: hacku (Quit: Leaving)
17:56:10 --- quit: giraffe (Ping timeout: 256 seconds)
17:58:34 --- quit: dude12312414 (Ping timeout: 240 seconds)
17:59:35 --- join: unixpickle (~alex@2601:645:8103:60b6:5853:94ec:b7d:2d3b) joined #osdev
18:06:37 --- quit: guest_01010101 (Quit: Saindo)
18:12:02 --- quit: Belxjander (Ping timeout: 265 seconds)
18:16:07 --- join: giraffe (skarn@gateway/shell/firrre/x-jrixonayozucvkbs) joined #osdev
18:17:13 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
18:26:33 --- quit: daniele_athome (Ping timeout: 260 seconds)
18:27:51 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
18:30:03 --- quit: sortaddsort (Remote host closed the connection)
18:35:19 --- quit: heat (Ping timeout: 255 seconds)
18:38:18 --- join: bcos (~bcos@CPE-58-170-82-208.lns2.way.bigpond.net.au) joined #osdev
18:38:58 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
18:41:07 --- quit: John___ (Read error: Connection reset by peer)
18:42:04 --- quit: alyptik (Ping timeout: 256 seconds)
18:44:40 --- join: alyptik (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
18:49:55 --- quit: fusta (Ping timeout: 264 seconds)
18:52:56 <variable> ""I’ve just realized that the P0 disclosure demonstrated all 2 hardest CS problems: 1) cache invalidation 2) naming things 3) off-by one errors (2 names/3 vulns) 0) guaranteed execution order""
18:53:12 <geist> hah
18:53:18 <Kazinsal> Brilliant
18:53:50 <variable> I can't take credit
18:53:54 <variable> https://twitter.com/IgorSkochinsky/status/949331337596538880
18:53:55 <bslsk05> ​twitter: <IgorSkochinsky> I’ve just realized that the P0 disclosure demonstrated all 2 hardest CS problems: 1) cache invalidation 2) naming things 3) off-by one errors (2 names/3 vulns) 0) guaranteed execution order
18:55:50 --- quit: zng (Ping timeout: 248 seconds)
18:56:50 --- quit: Belxjander (Ping timeout: 240 seconds)
18:57:40 --- join: bcos_ (~bcos@CPE-58-170-204-121.lns7.win.bigpond.net.au) joined #osdev
18:58:00 --- join: zhiayang (~zhiayang@138.75.223.203) joined #osdev
18:58:29 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
18:59:50 <doug16k> lol
18:59:53 --- quit: bcos (Ping timeout: 265 seconds)
19:01:45 <doug16k> lol, MSI-X is easy!
19:01:57 <doug16k> should have added it a while ago
19:02:26 <geist> yeah it's pretty neat
19:08:38 --- join: fusta (~fusta@139.179.50.177) joined #osdev
19:09:01 <gamozo> is it supported on everything or is it Intel/Amd specific?
19:09:58 <geist> MSI-X? it's a PCIe feature. I can personally confirm it works on non x86s
19:10:18 <gamozo> oh wow, i had no idea
19:10:20 <geist> it's basically a fancier MSI, which i think technically showed up in the tail end of the PCI era
19:13:22 --- join: navidr (uid112413@gateway/web/irccloud.com/x-vdsvcwteynsnnwkx) joined #osdev
19:13:31 <doug16k> it's basically an extended MSI that 1) allows for a lot more vectors per device, and 2) allows you to route each individual IRQ to different addresses (which makes it capable of routing them to different processors)
19:14:30 <doug16k> so, for example, if you have per-cpu nvme completion queue IRQ vectors, you can send the IRQ to the appropriate CPU directly
19:15:33 <geist> though to be fair i think you can do that with MSI, but you still only get 8
19:15:41 <geist> and they have to be contiguously allocated in an annoying way, iirc
19:15:50 <doug16k> you can't, only the data value changes in MSI
19:15:57 <doug16k> you can only use multiple vectors in MSI
19:16:08 <geist> oh hmm
19:16:11 <doug16k> one address for whole device on MSI
19:16:28 <geist> ah and on x86 the target is encoded in the address
19:16:32 <doug16k> right
19:16:39 <doug16k> I thought that too until today
19:16:47 <geist> forgot about that. i think it works differently on ARM. since technically the address and format of MSI is machine specific
19:17:00 <geist> another fun one you'll see if you use lspci to poke at it on linux is the effect of iommus
19:17:13 <geist> if your machine is using an iommu, it *also* translates MSI, which makes sense
19:17:41 <geist> so in general if you look at the address/data field of msi it looks like nonsense, because it's primarily using like IRQ 0 for every device, and then there's some mechanism upstream to translate that at the iommu
19:17:58 <doug16k> yeah in a way I'm looking forward to when some crap device can't do 64 bit dma so I have an excuse to add IOMMU :D
19:18:42 <doug16k> ah, I see
19:20:56 <doug16k> I could add IOMMU for IDE PCI-DMA, but seriously, no
19:21:00 <doug16k> lol
19:21:15 <doug16k> eat hot memcpy IDE people
19:22:52 <doug16k> AHCI has a "64 bit capable" bit, but according to QEMU, windows has never checked it and just assumed 64 bit support (qemu had a bug where it reported not 64 bit capable)
19:23:05 <doug16k> so if windows never checked it, then it's safe to assume it is always 1
19:24:18 <doug16k> fairly safe*
19:24:45 <variable> lol
19:26:33 --- join: dude12312414 (None@gateway/shell/elitebnc/x-whbxbvqhjbwfhdrp) joined #osdev
19:27:26 --- quit: Belxjander (Ping timeout: 265 seconds)
19:29:54 <Kazinsal> https://twitter.com/0xMatt/status/949827175938637825
19:29:54 <bslsk05> ​twitter: <0xMatt> The internet and social media summed up: Some random guy attempting to win an argument by telling @taviso he doesn't know enough about web security. https://pbs.twimg.com/media/DS52xo2VQAA6bya.jpg
19:32:54 <_mjg> lol
19:32:54 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
19:33:40 <Kazinsal> More related to the channel at hand, has anyone seen any documentation from Intel on architectural differences in the Xeon Scalable architecture?
19:33:49 <variable> bslsk05: lol
19:37:26 --- join: bcos (~bcos@CPE-101-103-3-14.lnse1.fli.bigpond.net.au) joined #osdev
19:40:58 --- quit: bcos_ (Ping timeout: 265 seconds)
19:42:43 --- quit: variable (Quit: Found 1 in /dev/zero)
19:47:25 --- quit: dude12312414 (Quit: Segmentation fault: 11)
19:56:21 --- join: dude12312414 (None@gateway/shell/elitebnc/x-vxulxplzlbdwttos) joined #osdev
19:57:57 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
20:03:16 --- quit: gdh (Quit: Leaving)
20:10:06 --- quit: ohnx (Ping timeout: 250 seconds)
20:15:19 <doug16k> wow, I really should have per-cpu IDTs. on a threadripper with dual nvme it would eat up 64 vectors right there
20:16:43 <doug16k> hmm... I could actually make them all use the same vector when I am distributing the interrupts across cpus
20:17:44 <geist> yeah i'm not sure anyone really does fully separate IDTs that way
20:17:55 <geist> you should probably come in via one vector, but then have a per cpu thing
20:18:40 <geist> though i think in practice linux at least tends to allocate a new number for each of those
20:18:51 <geist> but i guess that has limitations and you'll eventually chew up all of your vectors
20:19:30 <doug16k> I have an interrupt allocator (and MSI aligned multiple vector allocator) and all that, just worried about running out with a heavily provisioned machine
20:20:03 <doug16k> but yeah, if I am distributing them across cpus, they can all share one IDT vector
20:21:03 * geist nods
20:21:16 <geist> you probably wont any time soon
20:21:35 --- quit: navidr ()
20:22:56 <doug16k> pathological scenario: ahci with 32 IRQs + 2 * nvme with 32 each == 96, plus quad function nic... yeah, probably won't run out but it's cutting it close
20:23:17 <doug16k> if I do nvme/msi-x properly it's 1 for each
20:23:51 <doug16k> I could even spread the ahci across cpus so it's a cpu per-port
20:24:04 <doug16k> yeah, that fixes the running out problem completely
20:25:37 <doug16k> well, I mean, target cpu = port index % cpu count
20:29:05 --- join: adminseodwn (~archer@unaffiliated/remcwo9o) joined #osdev
20:29:13 <doug16k> (technically, ahci does a crap thing where all of the ports past the MSI multiple-message count pile up on the last vector) :D
20:30:15 <doug16k> might not for msi-x, I didn't pay much attention to msi-x stuff when making that driver
20:31:55 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
20:33:31 <geist> http://newos.org/stuff/interrupts.txt is an older machine iv'e had. lets see about the 48 core
20:34:41 <geist> http://newos.org/stuff/interrupts.48.txt ah, wraps a lot
20:35:37 <geist> but if you can view the last one, the LSI contrller (mp2sas) seems to fire up 16 MSI-X vectors and distribute across the cores
20:36:19 <geist> when you think about it, tyou wonder why linux forces them to have their own vector, vs just a single vector with a dedicated cpu target per source
20:36:57 <geist> may be more of a software thing, because otherwise as you bring cpus on and offline, the higher level kernel doesn't know that the driver may now be targetting cpus that dont exist
20:37:00 <geist> so it makes some sense to still have them be separate vecotrs, or some sort of notion of a subvector, like 33.1 or 33.5 or whatot
20:42:08 --- quit: freakazoid0223 (Quit: IceChat - It's what Cool People use)
20:44:43 <doug16k> 48, lol
20:45:13 <geist> yeah the newer desktops issued at work are 56
20:45:25 <geist> this is the slightly older dual socket 12 core + HT
20:45:48 <doug16k> what do those crazy numbers mean? 524302-edge
20:47:03 <doug16k> I get crazy IRQ numbers on my machine too. why does linux do that?
20:47:57 <doug16k> this is my ryzen: https://gist.githubusercontent.com/doug65536/3462a1858a4158cf8cc84f45d8336f45/raw/48d38c8bcc55ec5eb806c25666d8a7b27a04b088/gistfile1.txt
20:48:37 <doug16k> 3674115-edge? really?
20:48:52 <doug16k> irq 3.6 million? wtf?
20:57:38 --- join: Humble (~hchiramm@2405:204:500c:2364:a69a:4253:13ad:de06) joined #osdev
21:03:11 <geist> yeah i dont get it either, but i think that has something to do with the iommu
21:03:23 <geist> try converting them to hex, maybe they're sane numbers with top bits set?
21:04:43 --- quit: quc (Ping timeout: 255 seconds)
21:05:06 <variable> reading C code older than 5 yrs ago is painful
21:05:09 <variable> if (foobar)
21:05:17 <variable> func(120), func2(120);
21:07:03 --- quit: Humble (Ping timeout: 275 seconds)
21:08:56 --- quit: wcstok (Quit: Leaving)
21:09:06 --- join: sinetek (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
21:10:19 --- join: quc (~quc@host-89-230-164-93.dynamic.mm.pl) joined #osdev
21:12:16 --- join: azonenberg_work (~azonenber@2001:470:ea80:2:2ab2:bdff:fe8a:439b) joined #osdev
21:12:58 <jjuran> variable: Pain is timeless.
21:15:13 --- quit: awang (Ping timeout: 265 seconds)
21:15:15 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:16:51 --- join: sdfgsdf (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
21:16:51 --- quit: sdfgsdfg (Remote host closed the connection)
21:18:28 --- quit: lucebac (Quit: No Ping reply in 180 seconds.)
21:18:44 --- join: lucebac (~lucebac@lucebac.net) joined #osdev
21:18:44 --- quit: lucebac (Changing host)
21:18:44 --- join: lucebac (~lucebac@unaffiliated/lucebac) joined #osdev
21:20:03 --- join: Humble (~hchiramm@223.186.43.204) joined #osdev
21:24:45 --- quit: marienz (Read error: Connection reset by peer)
21:25:38 --- quit: tacco\unfoog (Ping timeout: 260 seconds)
21:28:30 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
21:40:03 --- quit: quc (Remote host closed the connection)
21:40:19 --- join: quc (~quc@host-89-230-164-93.dynamic.mm.pl) joined #osdev
21:47:35 --- join: bcos_ (~bcos@CPE-101-103-3-14.lnse1.fli.bigpond.net.au) joined #osdev
21:51:14 --- quit: bcos (Ping timeout: 268 seconds)
21:54:45 --- join: uvgroovy (~uvgroovy@pool-108-49-55-199.bstnma.fios.verizon.net) joined #osdev
21:57:36 --- quit: uvgroovy (Client Quit)
21:57:54 --- join: uvgroovy (~uvgroovy@pool-108-49-55-199.bstnma.fios.verizon.net) joined #osdev
22:00:41 --- quit: uvgroovy (Client Quit)
22:02:56 --- join: uvgroovy (~uvgroovy@pool-108-49-55-199.bstnma.fios.verizon.net) joined #osdev
22:06:47 --- join: lkolstad (~ljk@c-24-16-12-195.hsd1.wa.comcast.net) joined #osdev
22:09:18 --- quit: uvgroovy (Quit: uvgroovy)
22:09:33 --- join: uvgroovy (~uvgroovy@pool-108-49-55-199.bstnma.fios.verizon.net) joined #osdev
22:17:16 --- join: oaken-source (~oaken-sou@p3E9D3A2F.dip0.t-ipconnect.de) joined #osdev
22:30:04 --- quit: quc (Remote host closed the connection)
22:30:17 --- join: quc (~quc@host-89-230-164-93.dynamic.mm.pl) joined #osdev
22:40:23 --- quit: zwliew (Quit: Connection closed for inactivity)
22:53:24 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:55:17 --- join: unixpickle (~alex@2601:645:8103:60b6:58b1:1a42:f695:f11e) joined #osdev
22:56:08 --- quit: unixpickle (Client Quit)
22:59:37 --- join: unixpickle (~alex@2601:645:8103:60b6:4d51:902b:296e:2c0b) joined #osdev
23:03:51 --- quit: unixpickle (Client Quit)
23:06:32 --- join: user10032 (~Thirteen@90.209.104.11) joined #osdev
23:10:46 --- quit: Belxjander (Ping timeout: 248 seconds)
23:12:07 --- join: FMan (~fooman@dygkbxrk430qsl-bjchzt-4.rev.dnainternet.fi) joined #osdev
23:13:17 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:13:30 <gamozo> why are there so many codebases that can't build without optimizations
23:13:43 <gamozo> bootloaders/early stages in kernels? sure, I get it, you're size constained
23:13:45 <gamozo> anything else???
23:15:59 <jjuran> gamozo: I have programs that won’t build with -O0 under certain toolchains, because the linker sucks and thinks that functions must be defined even if they’re not called anywhere.
23:16:24 --- quit: variable (Quit: Found 1 in /dev/zero)
23:16:40 <gamozo> I think that's the most common one I've seen
23:16:47 <gamozo> almost always linking issues
23:18:56 --- quit: dbittman (Ping timeout: 246 seconds)
23:21:20 --- quit: davxy (Ping timeout: 240 seconds)
23:22:02 --- join: davxy (~davxy@unaffiliated/davxy) joined #osdev
23:23:36 --- join: sortaddsort (~archer@unaffiliated/remcwo9o) joined #osdev
23:25:42 --- quit: adminseodwn (Ping timeout: 248 seconds)
23:26:21 <doug16k> geist, yeah I see now. they look like powers of two with an offset added to them. thanks
23:30:37 --- quit: uvgroovy (Read error: Connection reset by peer)
23:41:31 --- quit: davxy (Ping timeout: 252 seconds)
23:42:20 --- join: Tanjoodo (~Tanjoodo@69in.space) joined #osdev
23:43:50 --- quit: Belxjander (Ping timeout: 248 seconds)
23:44:17 --- join: davxy (~davxy@unaffiliated/davxy) joined #osdev
23:44:50 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:45:14 <sinetek> Valgrind in particular needs -O0 or -O3
23:45:18 <sinetek> Depending what you're doing
23:45:47 <sinetek> I've seen some other examples where -O0 doesn't work
23:46:20 --- quit: raphaelsc (Ping timeout: 240 seconds)
23:49:31 --- quit: jakogut (Ping timeout: 240 seconds)
23:50:46 --- quit: oaken-source (Ping timeout: 248 seconds)
23:55:34 --- quit: davxy (Ping timeout: 248 seconds)
23:56:26 --- join: alphawarr1or (uid243905@gateway/web/irccloud.com/x-mtshjftiatglakyx) joined #osdev
23:57:19 --- join: davxy (~davxy@unaffiliated/davxy) joined #osdev
23:58:44 --- join: glauxosdever (~alex@ppp-94-65-238-238.home.otenet.gr) joined #osdev
23:59:59 --- log: ended osdev/18.01.06