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=19&m=5&d=14
12:33:16 <doug16k> neat. I can breakpoint the ud ISR by peeking at efi IDT :)
12:34:53 <doug16k> OVMF's interrupt entry points: https://gist.github.com/doug65536/09901c4944e735e7c99e461db8951000
12:34:55 <doug16k> ouch
12:35:53 <doug16k> trampoline to other planets goes to next street over
12:42:09 <doug16k> \o/ made it through EFI bootloader without triggering any UD
01:06:36 <bcos> doug16k: The worst part is what happens after that - from what I've been seeing all exceptions end up stuck in a "while local variable that can't change hasn't changed" loop, with no error message or indication that something crashed
01:07:35 * bcos has been considering creating a copy of the firmware's IDT (in case it's in ROM) and replacing all the exception handlers, just to get a "Ooops dump" out of it
01:46:21 <FreeFull> bcos: Memory corruption, yay
01:46:32 <FreeFull> Always the worst kind of bug
01:47:02 <_mjg> dude
01:50:33 <FreeFull> I mean, it could be something else. Hopefully is
01:50:49 <zid> FreeFull is a bug racist
01:57:24 <doug16k> this is ub? -> uintptr_t tss_addr = uintptr_t(&base->reserved0);
01:57:36 <zid> IDB
02:00:14 <doug16k> bcos, wow
02:01:26 <doug16k> OVMF triple faults on #UD
02:02:39 <bcos> doug16k: Hrm. After you loaded TSS?
02:03:02 <doug16k> this is in efi loader. I turned on UD2-on-UB ubsan thing
02:03:13 <doug16k> there was one thing which I fixed
02:03:34 <doug16k> didn't exit boot services yet if that's what you meant
02:03:42 <bcos> I think I only get the infinite loop
02:04:09 <doug16k> x86_64 right?
02:04:32 <bcos> (testing) - yes x85_64 in VirtualBox
02:06:29 <bcos> Yeah - UB2 ends up at ".l1: mov rax,qword [rbp+0x30]; test rax,rax; je .l1" loop
02:06:40 <doug16k> yes that's right
02:06:43 <doug16k> 0x8(%rsp),%rax
02:06:48 <doug16k> forever
02:07:11 <doug16k> ah right the triple fault was when it ud'd my gdt init, crying about union misuse
02:07:15 <doug16k> I guess
02:07:57 <doug16k> maybe that's their way of making a generic debug-break
02:08:07 <doug16k> you attach, set that to 1, and continue
02:08:26 <doug16k> need to be wizard enough to look at stack with hexdump of rsp
02:10:20 <bcos> Hrm - set RAX = 1 and single-stepped, and the thing cleaned up and returned from the exception (back to my ud2)
02:11:01 <doug16k> my loop is exactly: 0x7fb1b4a4: mov 0x8(%rsp),%rax ; test %rax,%rax je 0x7fb1b4a4
02:11:20 <doug16k> interesting that yours has rbp on
02:11:48 <bcos> Qemu people might've compiled with some "fomit_framepointer" - not sure
02:12:33 <bcos> (hrm - might even be different compiler - oracle might use Microsoft's)
02:13:20 <bcos> Behaviour is same though - still bad/useless :-)
02:13:40 <doug16k> ya
02:14:28 <doug16k> so I suppose for a while they will ignore IDT patching, then later, surprise!, now we kill your bootloader if it touches it
02:14:40 <doug16k> like windows kernel
02:17:05 <bcos> The scary part (for me) is the design of my boot involves "sandboxing" (e.g. running modules at CPL=3 in their own virtual address space, and switching CR3, GDT, IDT between mine and UEFI's)
02:19:15 <bcos> ^ worked very well for the ("BIOS only") previous version of my OS
02:19:32 <bcos> :-)
02:19:43 <doug16k> preemption or cooperative?
02:20:43 <doug16k> oh I see what you meant
02:20:50 <doug16k> in uefi it is cooperative though right?
02:21:27 <doug16k> I can imagine timers working but that would be scary
02:21:39 <bcos> Co-operative
02:22:48 <doug16k> you could use that smp run-on-another-processor thing if you want that
02:23:09 <doug16k> then just IPC something with uefi thread for I/O or w/e
02:23:32 <bcos> Basic idea is to build a wrapper around whatever the firmware is so boot loader can abstract firmware details; then have a second "firmware and boot device independent" piece that runs with paging, etc, which uses the "sandboxed modules" for things like video output, CPU detection, etc
02:24:01 <bcos> ..but where everything is explicit calls sort of
02:25:09 <bcos> (e.g. a "switch to XXX and call its API with these parameters" interface that takes care of the switching)
02:55:41 <eryjus> oh mother fucker!
02:56:34 <eryjus> ok, so my ioapic code was not initializing the 8259 PIC, and that was what was causing the problems with that weird #DF.
02:57:13 <eryjus> as soon as I added the code to remap the 8259 and then promptly disable it, it worked
02:57:20 <eryjus> doug16k: ^
02:58:11 <zid> I even mentioned that!
02:58:15 <bcos> eryjus: In that case (forgot to mask everything in PIC chips), you probably also want to add IRQ handlers for PIC chip's spurious IRQs (they can't be masked)
02:58:35 <bcos> *chips'
02:58:49 <bcos> (like, one for master and another for slave)
02:59:00 <brimonk> Someone want to help me debug my linker error? I'm getting "warning: cannot find entry symbol _start; defaulting to 0000000000100000" from my linker, and I get that it can't find the _start function, but why could this be happening in the first place?
02:59:10 <zid> where is _start
03:00:11 <eryjus> bcos: no, it was masked.. just not remapped.
03:00:34 <zid> Can you just map the pic to some range you don't use, and then know it's just the pic being dumb?
03:00:41 <eryjus> zid, i'm sorry -- if you mentioned that, i totally missed it
03:00:55 <zid> well, we talked about having to disable the pic etc
03:01:25 <eryjus> and it was there (and you made me look!)
03:02:37 <brimonk> zid: well, now that you mention it, I don't see a _start function in my binary output.
03:02:48 <zid> output? It's moaning about the input
03:02:53 <zid> execution is supposed to start *somewhere*
03:02:59 <eryjus> brimonk, are you including the .o that has the _start label? are you exporting that label?
03:03:05 <bcos> brimonk: There's a linker script function to change its name (not sure - maybe "entry(main)" would)
03:03:21 <zid> entry(main) is almost certainly not what you want, though, unless you're not using C
03:03:42 <zid> and doesn't solve his problem, that he doesn't understand what an entry point is
03:03:56 <brimonk> Okay,
03:04:11 <brimonk> the boot.S, once it's assembled, the output has _start.
03:04:18 <brimonk> So, I'm just not linking properly with that.
03:04:20 <zid> okay, is the symbol exported from boot.S
03:04:29 <zid> and are you including its .o/.S in the line where the linker error happens
03:06:01 <doug16k> eryjus, nice
03:06:29 <brimonk> zid: The linking logic in my Makefile is off, it seems.
03:06:32 <eryjus> :D
03:06:45 <doug16k> eryjus, oh no way, 8259's still sitting where BIOS had them?
03:07:13 <eryjus> they were, when I remapped them it worked
03:07:17 <doug16k> awesome
03:07:32 <zid> doug16k: What's the plan there, move the PIC ranges off the IRQ ranges to some garbage interrupt numbers like 200, then just int_200(){ printf("Spurious PIC interrupt"); }
03:07:32 <eryjus> once again, thanks for the help
03:07:45 <doug16k> np
03:07:50 <bcos> Confusing (using APIC, PIC chip masked, but something came from PIC chip?)
03:07:51 <doug16k> zid, I put them 240-255
03:07:56 <zid> so yes then? cool
03:07:57 <doug16k> lowest priority
03:08:01 <doug16k> yes
03:08:01 <eryjus> zid, yes, I will do something like that as well
03:08:17 <zid> I could probably switch over to apic just from irc convos now :P
03:09:18 <eryjus> zid, it took me longer to understand that it was a split architecture than anything else (apart from debugging this crap)
03:09:28 <zid> a split arch?
03:09:33 <doug16k> yes with alignment restrictions. 8-vector boundary I believe
03:09:54 <brimonk> On the bright side, now I get a nice green VGA screen.
03:09:59 <doug16k> probably not a bad idea to do that anyway
03:10:01 <brimonk> Which isn't quite what I wanted, but the linker error is fixed.
03:10:08 <eryjus> lol... the ioapic at the end of the bus (southbridge if I recall the term right) and a lapic with each core
03:10:15 <bcos> zid: Correct way is to mask, then do a nop or two for fun; then CLI (to prevent stale IRQs getting jammed in PIC); then remap PIC, installed 2 spurious IRQ handlers (not a range - only IRQs 7 and 15); then setup APICs
03:10:22 <zid> what does that mean though
03:10:33 <zid> yea I do a nop or two for fun
03:10:57 <bcos> (mostly so BIOS/firmware/whatever has a chance to handle any IRQs that occure while you mask)
03:11:20 <bcos> (and ensure there are no "pending IRQs" by the time you CLI)
03:11:26 <zid> okay but
03:11:35 <zid> what does "understanding it's a split architecture" mean
03:11:43 <doug16k> eryjus, there can be multiple ioapics. my main machine has two
03:12:03 <doug16k> so it's not hypothetical at all. make sure that works
03:12:15 <eryjus> agreed.
03:12:24 <doug16k> might be a bug or two in that area at worst, not a big deal
03:12:45 <zid> my machine appears to only have one
03:12:57 <doug16k> zid, got a ryzen?
03:13:36 <zid> no no, no numa for me
03:14:08 <doug16k> not that big. a big desktop ryzen has 2 ioapics
03:14:45 <doug16k> my 2700x does and my 1700 and my 1800x do too
03:15:08 <doug16k> I don't know if the ones with less cores also do
03:15:21 <zid> all the ones that are numa presumably do
03:15:28 <zid> which is.. all the ryzens, afaik?
03:15:39 <doug16k> that's not numa really
03:15:59 <doug16k> numa is when some phys mem range is faster for you and another isn't, and vice versa for other domain
03:16:04 <zid> except it is? It's pairs of dies bolted together across a link and they have seperate dram
03:16:10 <doug16k> no
03:16:22 <doug16k> there is a split L3. they have the same distance to memory
03:16:38 <doug16k> threadripper is numa
03:16:53 <doug16k> it's two of what I said, with their own interfaces to their own sticks of memory
03:16:53 <bcos> They invented new terminology - "sub-domains", etc
03:17:13 * zid forgot non 'threaderipper' ryzens existed
03:17:16 <doug16k> since both have their own sticks, it is faster to use own sticks, and more latency to use other one's sticks
03:17:19 <doug16k> that's uma
03:17:21 <doug16k> numa*
03:30:26 <brimonk> Alright, I have a new problem.
03:30:30 <brimonk> I can't access VGA memory.
03:30:35 <zid> is paging enabled
03:30:40 <brimonk> Paging isn't enabled.
03:30:43 <zid> are you aware that 0xA000 real mode is actually 0xA0000
03:30:47 <zid> because of segmentation
03:30:53 <brimonk> ...
03:30:54 <brimonk> No?
03:30:58 <Mutabah> zid: *segment 0xA000 is that
03:31:29 <zid> Mutabah: and most people learn VGA by setting es to 0xA000, and org 0x7C0 etc forgetting that addr = seg*16+offset
03:31:36 <doug16k> geordi, << (0xA0000 / 1024) << "K"
03:31:36 <geordi> 640K
03:32:07 <brimonk> What if I told you that I was trying to follow the BareBones thing.
03:32:16 <zid> never read it
03:32:39 <brimonk> So, I don't think I enabled paging. How would I go about doing that?
03:32:42 <doug16k> if you havent done much real mode programming, the "segment times 16" thing won't be as obvious
03:32:45 <zid> don't do that
03:32:50 <brimonk> zid: Why not?
03:32:53 <Mutabah> brimonk: First thing - what do you mean by "can't access VGA memory"
03:32:56 <zid> it's a bit beyond you so far
03:33:03 <Mutabah> brimonk: what are you doing, and what's happening (or not happening)
03:33:05 <zid> get things working before you get things working on top of other things
03:33:53 <brimonk> Mutabah: I mean, when I do this, https://termbin.com/tbqv first array access to term->buf, I get SIGSEV
03:34:01 <brimonk> zid: sounds reasonable to me
03:34:15 <zid> at least the address looks right
03:34:18 <brimonk> Keep in mind, I do have debugging information enabled, and that might like, ruin everything.
03:34:19 <Mutabah> brimonk: ... SIGSEGV
03:34:22 <zid> b8000 not 8b00 :P
03:34:31 <brimonk> wha
03:34:39 <brimonk> Hmm
03:34:41 <zid> just had this conversation I think
03:34:45 <Mutabah> How can you get a sigsegv in freestanding code?
03:34:49 <brimonk> No, that's 0xb8000
03:34:50 <brimonk> well,
03:34:55 <brimonk> That's just what gdb said.
03:35:01 <zid> and who is telling you you faulted
03:35:08 <zid> as presumably you don't have interrupt handlers etc
03:35:12 <brimonk> "Program received signal SIGSEGV, Segmentation fault." gdb
03:35:13 <brimonk> I don't.
03:35:17 <zid> that's gdb crashing isn't it
03:35:24 <Mutabah> brimonk: How are you running this code?
03:35:24 <brimonk> I dont' think so.
03:35:26 <bcos> 0xB80000 is the right address for "text mode VGA with 32-bit code and segment limits = 0"
03:35:29 <doug16k> the gdbstub is trying to have a reasonable signal name for different break causes
03:35:38 <brimonk> qemu-system-i386 -kernel myos.bin
03:35:38 <bcos> *B8000
03:35:38 <zid> is this qemu?
03:35:40 <zid> yes
03:35:46 <brimonk> Then I'm doing the remote into it through gdb
03:36:10 <brimonk> I do have the S flags to actually have the remoting work.
03:36:15 <brimonk> Just didn't type them.
03:37:21 <doug16k> wait though, that should have been SIGQUIT shouldn't it?
03:37:40 <zid> you're the qemu expert I think
03:37:42 <zid> you tell us :P
03:38:05 <doug16k> what should have happened is a fault when it tries to page fault, then that is a double fault, which faults, now it breaks into gdb with sigquit
03:38:29 <zid> and qemu isn't like to do anything weird like deliver unhandled cpu exceptions to gdb?
03:38:51 <zid> not that this should be a fault in unsegmented protected mode like he's probably in
03:38:54 <doug16k> let me try it
03:38:57 <brimonk> All I know, I think, is that I get "Program received signal SIGSEGV, Segmentation fault." on the console.
03:39:01 <zid> or does barebones make you set up the gdt
03:39:04 <zid> before this point
03:39:23 <brimonk> There's a comment in the linker script that talks about it, but I don't think there's any asm that does it.
03:39:34 <zid> link me this page
03:39:38 <zid> did you do all the steps up to this point
03:39:38 <brimonk> https://wiki.osdev.org/Bare_Bones
03:39:41 <brimonk> "Yes"
03:39:42 <zid> so I can get a sence of the environment
03:39:48 <zid> sense
03:39:52 <brimonk> Should I just plop what I have up on github?
03:40:38 <zid> so this is just a multiboot image with that snippet of assembly?
03:40:40 <brimonk> (or somewhere else)
03:40:44 <brimonk> And some C.
03:41:22 <zid> give me the ELF
03:42:10 <brimonk> It's that you can't index into an array with a size_t?
03:42:11 <brimonk> Ew.
03:42:14 <brimonk> zid: how?
03:42:23 <zid> dropbox, google drive, discord, email, http, ftp
03:42:25 <zid> gopher
03:42:34 <zid> base64 encode it and gist it
03:42:45 <zid> carrier pigeon me an SD card
03:43:02 <zid> record it as an mp3 in morse code after base64ing it, then soundcloud it
03:43:22 <zid> scp
03:43:36 <doug16k> nope. sigquit like I thought
03:43:38 <zid> netcat
03:44:08 <doug16k> the example gdbstub has the behaviour I mentioned though, must have been thinking that
03:45:45 <brimonk> zid: I base64'd it, just like you asked: http://dpaste.com/3J7JP93
03:45:53 <brimonk> I still don't get VGA on the screen.
03:45:56 <brimonk> erm
03:46:01 <brimonk> *characters on the screen
03:47:54 <zid> none of that assembly is there
03:48:15 <zid> _start mov esp, offset ALIGN; call K_Main; cli; hlt; jmp hlt_instruction
03:48:54 <zid> oh that's all the assembly that's there, it's all bloody comments
03:49:21 <brimonk> Yeah.
03:51:16 <doug16k> brimonk, you get that sigsegv on what console? qemu crashes and prints that to console where you ran qemu?
03:51:24 <doug16k> just curious
03:51:29 <brimonk> doug16k: In the console where I'm running gdb.
03:51:33 <brimonk> Nothing happens in qemu.
03:51:41 <zid> hmm why is my hex rays not working
03:51:53 <brimonk> zid: I gave you debug info and everything!
03:52:43 <doug16k> brimonk, did you do a gdb command to break on all exceptions or signals or something?
03:52:59 <brimonk> Not that I know of.
03:53:27 <brimonk> That problem seems to have gone away by not using a size_t in C.
03:53:30 <brimonk> Using a real integer.
03:53:43 <zid> I think my fake licence fake expired?
03:53:57 <doug16k> umm. don't start using "real integers" because of some fluke crap like that
03:54:18 <doug16k> it's a typedef
03:54:27 <zid> where did you change size_t
03:54:27 <doug16k> size_t is a "real integer" isn't it?
03:54:48 <brimonk> In K_TermInit
03:55:03 <brimonk> Changed my "curr" from size_t to s32
03:55:07 <brimonk> (int32_t)
03:57:00 <zid> diassembly looks vaguely correct, even if I can't get my hex rays working
03:58:06 <brimonk> Hmmm
03:58:18 <doug16k> what disassembly? from the base64?
03:58:22 <zid> yea
03:58:29 <brimonk> I should have just posted the actual disassembly.
03:58:38 <zid> I don't trust your diassembly :P
03:58:41 <zid> I wanted the elf
03:58:52 <zid> I trust IDA and readelf a lot more
03:59:43 <zid> The math here is fairly strange though
03:59:51 <zid> what's K_VGA_WIDTH defined like, 80 presumably
03:59:53 <zid> but maybe not
04:00:12 <brimonk> Yeah.
04:00:16 <zid> ah I see what it's doing
04:00:18 <brimonk> WIDTH is 80, HEIGHT is 25.
04:00:29 <zid> y*4*4*5 + x lol
04:00:41 <brimonk> ?
04:00:48 <doug16k> optimizer I guess
04:00:51 <zid> That's what it compiled to
04:00:55 <zid> 4*4*5 = 80
04:01:00 <bcos> LEA to avoid MUL
04:01:01 <zid> but you can do 4*4*5 with adds and shifts
04:01:05 <zid> it didn't even use lea
04:01:27 <bcos> How did it *5 without LEA?
04:01:35 <zid> adds and shifts
04:01:46 <zid> mov eax, y; mov edx, eax; shl eax, 4; add eax, edx
04:01:51 <bcos> Ah - so y*4*4*4+y
04:01:58 <bcos> D'oh
04:02:38 <brimonk> fg
04:02:41 <bcos> Anyway, that's silly - should've "lea *5; shift"
04:02:41 <brimonk> oops
04:02:47 <zid> bcos: agreed
04:02:58 <zid> lea edx, [eax+eax*4]
04:03:11 <doug16k> fun how decoding is so hard on x86, then the core is such that using more instructions is faster, so decode is harder still
04:03:33 <brimonk> I mean, the biggest problem is even if I do my K_TermInit with 'A' instead of ' ', that doesn't show up on the display either.
04:04:15 <zid> I can't actually see where term is initialized etc
04:04:20 <bcos> brimonk: Can you use GDB to look at VGA's memory and see if Qemu's window lies?
04:04:23 <zid> maybe because I didn't annotate the struct
04:04:37 <doug16k> brimonk, try this: __asm__ __volatile__ ("mov $'A',0xB80000");
04:04:37 <brimonk> K_TermInit is the function.
04:04:50 <doug16k> oops
04:04:52 <zid> Yea I'm in it
04:05:08 <doug16k> movw $0x741,0xB8000
04:05:09 <zid> ah found a mov [eax+8], 0xB8000h
04:06:01 <brimonk> Yeah.
04:06:07 <brimonk> doug16k: where do you want me to put that?
04:06:21 <doug16k> somewhere. it should put a white on black A at top left corner
04:06:24 <zid> well that was a fun waste of 10 minutes
04:06:28 <zid> i'd do the rest in qemu
04:06:28 <doug16k> first thing it does or whatever
04:06:34 <brimonk> kk
04:06:54 <brimonk> Well
04:06:58 <brimonk> I got an assembler message.
04:07:07 <brimonk> no instruction mnemonic suffix given and no register operands; can't size instruction
04:07:12 <doug16k> you got correction?
04:07:20 <brimonk> No.
04:07:20 <doug16k> __asm__ __volatile__ ("movw $0x741,0xB8000")
04:07:23 <brimonk> Ooooh
04:08:26 <brimonk> Well that works.
04:08:36 <doug16k> ok then your environment is sane, and it's the code
04:08:42 <brimonk> Great.
04:08:44 <zid> I didn't spot it though
04:08:49 <zid> kterminit looks fine
04:09:04 <zid> other than your loops being inside out
04:09:11 <brimonk> Yeah, ignore that for now.
04:09:17 <brimonk> baby steps
04:09:23 <zid> I mean, it's super weird, ofc
04:09:50 <zid> it should just be memset(term, 80*25*2, MACRO(' ', BLACK_AND_WHITE)); or whatever
04:09:53 <zid> idk what all the extra stuff is for
04:09:58 <zid> memsetw maybe
04:10:52 <bcos> rep stosd (with 2 chars per EAX)
04:11:08 <zid> stosw is plenty fast I should hope
04:11:17 <zid> not that I'd write it in assembly
04:13:02 <brimonk> You'd think that, but when I tried that, I got a half black, half green screen.
04:13:15 <brimonk> You need like, memset16 or something.
04:13:25 <doug16k> yes
04:13:55 <doug16k> std::fill
04:14:06 * doug16k ducks
04:14:18 <bcos> To fill it with STDs
04:14:21 <bcos> ;-)
04:22:56 <brimonk> Am I making VGA values wrong?
04:23:04 <zid> back to front values maybe?
04:23:07 <brimonk> Isn't is the lower 8 bits are the "value" and the upper 8 bits are the color?
04:23:23 <brimonk> `return (uint16_t) uc | (uint16_t) color << 8;`
04:23:25 <zid> If you swapped them, you'd expect a constant 'character' with different attributes
04:24:06 <brimonk> The inline asm is the only thing that still works.
04:24:08 <zid> It goes attrib char in memory order I think? that'd be char|attrib in a reg
04:24:19 <zid> which is infact, opposite to how you have it
04:24:23 <zid> if you're writing it as a short
04:24:54 <zid> Your test data wasn't very useful, I guess
04:25:06 <zid> I think I wrote 0x5555 or something because it had lots of nice bits set
04:27:50 <brimonk> Well, here's a question.
04:27:58 <brimonk> Do I have to set the video mode or something?
04:28:02 <brimonk> Because I probably don't do that.
04:28:08 <zid> your bios will have left you in one
04:28:16 <zid> usually 80x25 vga text, so you should be fine
04:28:23 <zid> grub can set arbitrary modes for you afaik
04:28:37 <brimonk> Hmmm
04:32:37 <brimonk> well, I got it.
04:33:01 <zid> you just got the endian incorrect on your u16 write?
04:36:25 <brimonk> Well.
04:36:28 <brimonk> Yeah, I guess.
04:36:29 <brimonk> But
04:37:11 <brimonk> It's like whenever I use a function/subroutine, it just doesn't work.
04:37:25 <zid> Maybe you're just not very good at C
04:37:47 <zid> did you remember to 'return' a value? Are you compiling with lots of warnings?
04:39:34 <brimonk> Well
04:39:44 <brimonk> It's probably because I need to return a 16 bit number.
04:39:46 <brimonk> Fuck me.
04:39:52 <zid> That may help
04:40:00 <brimonk> I'm pissed.
04:40:10 <brimonk> This'll have to continute tomorrow.
04:40:17 <brimonk> zid doug16k thanks for all of your help.
04:43:00 <doug16k> it does exactly what you say. that's why it is so great. that's also why it seems terrible sometimes.
04:44:29 <doug16k> except when it doesn't do what you said, which can happen when what you said has undefined behaviour
04:45:50 <doug16k> inline assembly can cause weird things, if you are inaccurate about the constraints. improperly aligned stack can cause very weird things
04:46:34 <doug16k> the compiler is totally relying on you following the ABI
04:47:27 <doug16k> telling the compiler incorrect information about asm can cause it to generate code that won't work
04:47:44 <doug16k> gcc believes you implicitly. clang is more picky
04:49:38 <doug16k> you could trash every register and tell gcc that you want x in eax and you don't change it, it will say sir yes sir and put x in eax and assume that everything else didn't change
04:51:52 <doug16k> it will even assume the value you wanted in eax is still there, since you said you didn't change it
11:13:48 <stisl> hi
11:14:48 <stisl> is there any trick to avoid the flickering of a moving mouse cursor when the framebuffer is tripple buffered?
11:16:55 <stisl> I added some mbfence's on every framebuffer so that the cached data should normally be the newest
11:18:26 <stisl> On other operating systems it is also flickering but not so hard
05:06:18 <gamozo> New CPU bugs today :)
05:18:18 <lava`> ^^
05:18:32 <lava`> https://cpu.fail/
05:19:01 <Bitweasil> Oh ffs.
05:19:37 <Bitweasil> I like the FAQ. Short, simple, and to the point.
05:19:46 <Bitweasil> "Yup. You're affected. No, you can't tell if you are. Have fun."
05:22:07 <lava`> ^^
05:22:42 <gamozo> :)
05:22:54 <gamozo> Just turn off hyperthreading
05:22:57 <gamozo> you're fine
05:23:05 <gamozo> oh also rewrite your schedulers
05:23:15 <gamozo> and flush all internal CPU caches on every privilege transition
05:23:17 <gamozo> it's not that bad
05:24:29 <Bitweasil> Yeah, Theo was right about hyperthreading.
05:24:35 <Bitweasil> I already disabled it on all my boxes.
05:24:43 <Bitweasil> (months back)
05:24:48 <Bitweasil> (year and so? Some long while ago)
05:24:50 <aalm> .theo
05:24:51 <glenda> Did they pay you to write all that text?
05:25:14 <Bitweasil> glenda, ?
05:25:27 <aalm> .theo
05:25:27 <glenda> Whatever you're doing, it is wrong.
05:25:29 <aalm> a bot
05:25:45 <Bitweasil> At this point, I think the right approach is to simply treat computers as cooperative multitasking units. They cannot keep secrets inside the system boundaries.
05:25:55 <Bitweasil> Ah, sorry, just learned about this channel recently.
05:30:21 <renopt> (while still being competitively performant)
05:30:48 <renopt> it's not that we can't make pretty secure systems
05:31:09 <renopt> we just value performance and cost more
05:49:02 <jjuran> It's really cute how the page documenting attacks that are possible in untrusted execution environments expects that I have JavaScript enabled.
05:49:32 <Bitweasil> Heh. Yeah.
05:53:17 <gamozo> Nah it assumes the average person has javascript enabled
05:53:21 <gamozo> and that is overwhelmingly correct
06:14:54 <doug16k> so that RIDL attack for instance, requires me to already be able to control the value of a PTE? what?
06:15:21 <doug16k> I'm a security vulnerability too. you should see what would happen if I gain powerful telekinesis
06:15:57 <doug16k> Carry was too nice
06:15:58 <Bitweasil> If it lets you jump hypervisors, like L1TF, that's a big deal.
06:16:09 <Bitweasil> (haven't read the papers yeT)
06:16:12 <Bitweasil> (working on it)
06:19:31 <doug16k> Carrie*
06:19:47 <gamozo> RIDL does not require PTE control
06:19:55 <gamozo> L1TF does
06:21:58 <doug16k> foreshadow
06:22:47 <gamozo> yeah, L1TF == foreshadow
06:27:48 <doug16k> yay page 8
06:27:53 <doug16k> go amd :D
06:31:10 <doug16k> the really tricky part for intel now is whether they are going to release another generation that still has every bug
06:31:32 <Bitweasil> AMD is likely vulnerable to similar attacks, just different from Intel. But they're not the focus of as much effort lately.
06:31:35 <Bitweasil> Same for ARM.
06:31:41 <doug16k> likely?
06:31:57 <doug16k> as in your guess overrules a security research paper that says it is immune to that attack?
06:32:36 <doug16k> paper not infallible, but I have no evidence to the contrary
06:33:29 <doug16k> pretty safe to say that most if not all of the performance lead of intel is done by cheating like this
06:33:52 <gamozo> nobody has done AMD research really
06:33:57 <gamozo> I'm sure AMD is just as bad
06:34:02 <doug16k> it isn't
06:34:09 <doug16k> that's just intel fanboy talk
06:34:10 <gamozo> all the bugs to date have been found on Intel, and then tested on AMD
06:34:19 <doug16k> amd has some
06:34:19 <gamozo> I don't know of a single CPU researcher who is focusing on AMD
06:34:27 <gamozo> out of the 10+
06:34:42 <doug16k> ah so they get zero credit for not having asinine embarrassing bugs like intel did with meltdown
06:34:43 <gamozo> it's onyl Intel, because these bugs are mainly cloud issues
06:34:59 <gamozo> No, it's just that I'm sure AMD has equally bad bugs, nobody is looking
06:35:17 <doug16k> intel is incompetent
06:35:22 <gamozo> :P
06:35:35 <doug16k> how many features did they add that don't even work?
06:35:46 <gamozo> TSX, f00f, etc, etc
06:35:49 <doug16k> TSX? broken. SGX? broken,
06:35:50 <doug16k> yes
06:36:08 <gamozo> and there's a reason AMD has 0 datacenter presence
06:36:09 <gamozo> people want perf
06:36:13 <gamozo> nobody gives a fuck about security
06:36:26 <gamozo> this wont affect intel's bottom line, nobody cares
06:36:58 <gamozo> in fact, in 2 years datacenters will be forced to retool to new Intel CPUs such that they can compete with new cloud providesrs who don't have 30% slowdowns due to software mitigations
06:37:13 <gamozo> unless somehow AMD becomes competitive by then, but they failed to capture cloud with Ryzen
06:37:26 <gamozo> I'm not trying to say Intel is doing anything good here, but AMD is just still not competitive yet
06:37:41 <gamozo> and now people are locked into Intel-only features like TSX and SGX for many of their cloud applications
06:37:46 <gamozo> so good luck moving people to AMD
06:38:15 <gamozo> I spent 1 year trying to get Ryzen silicon in my lab, couldn't get it from over 5+ vendors I contacted
06:38:19 <gamozo> they're not focusing on cloud for some reason
06:39:23 <Bitweasil> doug16k, I didn't say AMD was vulnerable to the exact same attacks. I said it was likely vulnerable to some similar categories of attacks.
06:39:37 <Bitweasil> But it's not had the same focus that Intel has.
06:39:45 <doug16k> right so all people have to go is guess that and boom, amd sucks too
06:39:56 <Bitweasil> They were vulnerable to some of the Spectre class attacks, just not the same exact variants as Intel.
06:39:56 <gamozo> nope, not claiming AMD sucks
06:40:02 <Bitweasil> Yeah.
06:40:03 <gamozo> just being skeptical
06:40:08 <Bitweasil> We have to guess about the unknown unknowns.
06:40:17 <Bitweasil> Foreshadow/L1TF demonstrated that even Intel can't reason about this stuff.
06:40:18 <gamozo> it's like every time I see someone say "well my kernel is fine because I write good C"
06:40:28 <gamozo> and then we still havent seen a single kernel without catastrophic corruption bugs
06:40:28 <Bitweasil> (it broke SGX, and Intel would not have allowed that had they known about it)
06:40:33 <gamozo> so I just assume every kernel has security bugs
06:40:33 <doug16k> spectre is pretty bad, but meltdown is utterly ridiculous
06:40:47 <Bitweasil> L1TF is the worst one, as it lets you break virtualization and SGX boundaries.
06:41:09 <gamozo> L1TF was strange, it required the contents you were leaking to be in L1 cache
06:41:14 <gamozo> so it was a lot more limited than arbitrary physical reads
06:41:28 <doug16k> I mean, it's utterly ridiculous for intel to not have seen meltdown coming. they did, they put it in the manual. they said over and over that speculated loads may load things unexpectedly. they didn't care
06:41:31 <Bitweasil> Sure, but you could manipulate the guest's page tables to read host physical, if it were in L1.
06:41:37 <gamozo> MLPDS which came out today also crosses VM and SGX boundaries
06:41:45 <Bitweasil> Yeah, haven't read the papers yet. :/
06:41:59 <gamozo> it's all good :)
06:42:01 <Bitweasil> Google is turning off hyperthreading on ChromeOS, which is a big deal.
06:42:01 <gamozo> I've worked with all of them
06:42:07 <Bitweasil> https://sites.google.com/a/chromium.org/dev/chromium-os/mds-on-chromeos
06:42:09 <gamozo> I'm the first reporter of MLPDS
06:42:18 <gamozo> I found and reported it in March of 2018
06:42:40 <gamozo> and I've worked on PoCs and all of the others that came out today
06:42:42 <Bitweasil> Ah, awesome. I worked on Rowhammer for a while.
06:42:55 <Bitweasil> (back before the release of the initial exploits)
06:43:21 <gamozo> oh yeah, I never learned rowhammer :(
06:43:30 <gamozo> had a lot of peers working on it, but I never peeked over their shoulders
06:44:13 <gamozo> I wasn't really a CPU person before this. I just happened to have security research + os dev + optimization background
06:45:11 <Bitweasil> *nods*
06:45:15 <Bitweasil> Rowhammer was fun.
06:46:07 <doug16k> Bitweasil, so turning on STIBP isn't good enough? had to turn of SMT altogether?
06:46:28 <Bitweasil> doug16k, just reporting what I hear.
06:48:12 <gamozo> Most people are trying to do SMT but not schedule 2 sibling hyperthreads to different privileges
06:48:18 <Bitweasil> If the issue isn't the branch predictors, then why would STIBP solve anything?
06:48:19 <gamozo> which also requires gating when one sibling goes to do a syscall
06:48:43 <gamozo> todays issues require scheduler rewrites
06:48:52 <doug16k> Bitweasil, you know it has nothing to do with branch predictors I guess
06:48:56 <gamozo> and a new microcode patch which allows the OS to quickly clear internal CPU caches
06:49:23 <Bitweasil> Today's issues are unrelated to branch predictors, for the most part.
06:49:29 <doug16k> L!tF is mitigated already isn't it? SSBD
06:49:40 <gamozo> L1TF was mitigated way back in august or so
06:50:02 <doug16k> ah wait
06:50:13 <doug16k> no that one is where you do a barrier for L1 flush
06:50:38 <Bitweasil> L1TF required the instructions to flush L1 only, instead of blowing all the cache.
06:50:43 <gamozo> yeah
06:50:50 <gamozo> you could only leak things from l1
06:51:15 <Bitweasil> Why Intel made CLFLUSH unprivileged without the ability to disable it...
06:51:19 <Bitweasil> Still not sure on that one.
06:51:38 <gamozo> yeah
06:51:43 <gamozo> turning off clflush would be nice
06:51:52 <Bitweasil> It doesn't solve the problem, but it sure makes it harder.
06:51:53 <gamozo> already a way to turn off rdtsc which helps thwart real attacks
06:51:58 <doug16k> then they would just do a bunch of set conficts or whatever
06:52:04 <Bitweasil> ... sure makes it harder.
06:52:08 <gamozo> sure, you can use threads incremeting a counter to still do attacks. But come on, rdtsc makes it so much easier
06:52:23 <Bitweasil> On the other hand, rdtsc and crew let you get the time without a syscall.
06:52:29 <Bitweasil> Which apparently is done a /lot/ by some applications.
06:52:35 <Bitweasil> (or, without a kernel transition)
06:52:43 <gamozo> yeah
06:52:48 <doug16k> ryzen has an rdtsc divisor doesn't it?
06:52:55 <doug16k> you could divide it down to a few mhz
06:53:07 <gamozo> many OSes will hot-path using rdtsc all in user-space when you try to get a monotonic counter from the kernel
06:53:09 <Bitweasil> Reducing timer resolution doesn't help.
06:53:09 <doug16k> didn't try it but it seemed you could from their register guide
06:53:19 <doug16k> Bitweasil, no? why not
06:53:20 <Bitweasil> There are quite a few good papers (Gruss and crew have some) on using lower precision timers for high precision timing.
06:53:21 <gamozo> you can in a hypervisor I know
06:53:24 <Bitweasil> Shortcut: It works just fine.
06:53:26 <gamozo> I'm not sure if it works without a hypervisor?
06:53:43 <Bitweasil> Yeah, there's the TSC multiplier field in the VMCS, I'm not sure if you can program it through a MSR.
06:54:08 <gamozo> Bitweasil: that still hurts attacks cause you start to have to do averaging
06:54:18 <Bitweasil> No, you just wait until the next timer tick.
06:54:31 <Bitweasil> You wait for a tick, then do your thing, then count in a tight loop to the next tick.
06:54:31 <gamozo> yeah, but your data rate plummets
06:54:36 <Bitweasil> And you can tell if your event was long or short.
06:54:41 <Bitweasil> *shrug* Not by that much.
06:54:43 <gamozo> because you have downtime between ticks where you cant attempt a leak
06:54:53 <Bitweasil> k, but if the ticks are that slow, it's a useless clock.
06:54:57 <gamozo> at the end of the day browsers need high precision timers for video, etc
06:54:59 <gamozo> yup :)
06:55:17 <Bitweasil> You can jitter, and cause problems, but you start screwing with AV sync and such.
06:55:25 <gamozo> yeah, it's not really worth it
06:55:34 <gamozo> also these attacks are really more cloud oriented
06:55:39 <gamozo> and in a cloud situation I have ring0 in a guest
06:55:42 <gamozo> and just do w/e the fuck I want
06:55:53 <doug16k> performance.now() is millisecond precision
06:56:21 <doug16k> well, the number is 1000 per second. how finely it increments I don't know for sure
06:56:24 <gamozo> I also believe attacks without needing a timer is possible
06:56:44 <gamozo> I believe there are better ways to leak from speculation than just timing cache line presence
06:57:51 <doug16k> performance.now() used to have a bunch of digits of precision. looks like they floor() it or something now
06:58:23 <retpoline> .theo
06:58:24 <glenda> So what is learned here?
06:58:59 <doug16k> I learned that meteors may strike so I'm stupid for not being 20 metres underground
07:00:01 <gamozo> My job is to search for meteors, and I see a lot of them hit. So I like to assume that it's possible for them to hit at any time
07:00:34 <gamozo> And I get a bit jaded at everyone claiming that something is safe because nobody has looked for meteors there
07:00:45 <gamozo> when every time I've looked for meteors I've found them
07:00:58 <gamozo> But I also recognize some meteors are bigger than others, and I'm not here to fanboy :)
07:01:23 <doug16k> but doesn't it feel futile when, as said earlier, nobody cares about security, all they want is performance to save electricity
07:01:30 <gamozo> Yes, it does
07:01:38 <gamozo> I scream at people on a weekly basis because of this
07:01:54 <gamozo> I have to fight to convince people that remote code execution bugs in DHCP servers and clients need to get fixed
07:01:56 <Bitweasil> doug16k, I expect if you do a survey of gentlemen farmers in a few decades, you'll find a ton of former security people.
07:02:00 <gamozo> because that's just not obvious for some reason
07:02:09 <Bitweasil> Who use old tractors, and horses, and mechanical devices.
07:02:16 <Bitweasil> Because they're tired of everything being broken.
07:02:21 <Bitweasil> I have an ancient tractor.
07:02:25 <Bitweasil> Purely mechanical.
07:02:28 <Bitweasil> I can reason about it easily.
07:02:31 <gamozo> Lol I ranted about John Deere to my parents the other day
07:02:40 <Bitweasil> It doesn't have firmware. It has pushrods.
07:02:47 <gamozo> I know a few hackers in the farming industry
07:02:49 <Bitweasil> It leaks plenty, but not my data.
07:03:05 <Bitweasil> ... and I really should just replace the oil gauge, but it's not leaking that badly.
07:03:13 <Bitweasil> I don't like "things" on my network.
07:03:26 <Bitweasil> They're a bunch of broken, exploitable crap that will be abandoned in 3 years when the company gets bored.
07:03:29 <Bitweasil> See, "Google."
07:03:29 <doug16k> the channels and orifices in the carburettor are pushing the line between mechanism and magic though
07:03:38 <Bitweasil> To you, sure.
07:03:43 <Bitweasil> To people who grew up with them? Not so much.
07:03:55 <Bitweasil> And it's pretty easy to take it apart, clean them out, and be back to running.
07:03:57 <doug16k> unless it's a diesel, in which case, you win
07:04:05 <Bitweasil> A low compression, low power engine doesn't require fine precision in fueling either.
07:04:07 <doug16k> nothing is more mechanical than that
07:04:07 <Bitweasil> Nah, it's a gasser.
07:04:23 <Bitweasil> N series Ford.
07:05:13 <Bitweasil> But, yes, the security realm is depressing as hell lately.
07:17:00 <lava`> @gamozo are you @gamozolabs on twitter?
07:18:29 <lava`> [20:52:08] <gamozo> sure, you can use threads incremeting a counter to still do attacks. But come on, rdtsc makes it so much easier <---- depends
07:18:39 <lava`> we've played around with many things that were easier with counters
07:18:47 <lava`> the tricky part is getting counters run stable
07:19:00 <lava`> but once that's done, they have a much higher precision than rdtsc
07:21:37 <Bitweasil> Eh? rdtsc is either a literal cycle counter or running at some fixed rate higher than the clock rate.
07:21:45 <Bitweasil> ... possibly except turbo, but it's pretty darn precise.
07:21:47 <Bitweasil> And quite stable.
07:24:27 <lava`> no
07:24:36 <lava`> rdtsc is stable
07:24:39 <lava`> but far from precise
07:25:31 <lava`> check out slide 12 ff. https://gruss.cc/files/dresden19.pdf here
07:26:04 <lava`> and tell me whether you had the wtf moment on slide 14 ,9
07:26:05 <lava`> ;)
07:26:07 <jjuran> Why are untrusted programs granted the necessary CPU resources to pull off endless counter increments?
07:30:58 <Brnocrist> lava`: so with kpti and l1tf migitations in place this attack fails, right?
07:44:59 <Bitweasil> Interesting, I've not seen those slides. Thanks!
08:03:13 <lava`> Brnocrist: what? no
08:03:52 <lava`> Brnocrist: https://cpu.fail/ --- the first 4 boxes don't care about kpti and l1tf mitigations
08:04:25 <lava`> meltdown uc/l1tf uc, well, at least l1-flushing doesnt work as an l1tf mitigation
08:04:33 <lava`> so if you use that, one might still leak data
08:04:43 <lava`> does that mean you can throw kpti away? no
08:04:52 <lava`> otherwise you're exposed to worse than these ;)
08:07:49 <Brnocrist> lava`: I am still reading the first pdf :)
08:07:56 <lava`> which one?
08:08:08 <Brnocrist> zombieload
08:08:10 <lava`> ah
08:08:28 <lava`> if something's horrible in there (other than the zombie loads ;D) please let me know
08:24:36 <Brnocrist> lava`: but with kpti the direct mapping is not a thing anymore, how the data there can be leaked?
08:26:25 <lava`> well
08:27:31 <Brnocrist> it is also mentione in section 5.2
08:27:35 <Brnocrist> mentioned
08:27:40 <lava`> the load has to return some data
08:27:50 <lava`> in meltdown it returns the kernel data although it shouldn't
08:28:59 <lava`> in foreshadow it returns the cache data although it does not even have any virtual address (the present bit is not set)
08:29:29 <lava`> in these new attacks it returns data from load buffer, store buffer or line fill buffer although nothing matches
08:30:19 <lava`> store buffer: you have a store, someone tries to read, you do a *partial* address match for performance reasons and you continue with the data
08:31:43 <Bitweasil> It's basically "#YOLO" encoded in processor design.
08:31:51 <Bitweasil> "Partial match? No match? We forward anyway!"
08:32:01 <lava`> load buffer / line fill buffer: someone reads a memory location and leaves a stale load buffer or line fill buffer entry behind them. you also try to access something, but you experience a microarchitectural fault(*), then the processor continues by just taking whatever data is in the stale entry
08:32:07 <lava`> right
08:32:08 <Brnocrist> yeah, but it should work only if the direct map in kernel is mapped to userspace, with KPTI this is not true anymore
08:32:10 <Bitweasil> "CRAAAAAZY Core is CRAZY! He'll do anything for speed!"
08:33:02 <lava`> (*) microarchitectural faults require ucode assists... there are many cases where this can be triggered, e.g. setting the dirty bits in the TLB
08:33:29 <lava`> @Brnocrist no?
08:33:42 <lava`> Brnocrist: look at figure 2 in the zombieload paper
08:34:06 <lava`> meltdown is mitigated by KPTI because you cannot transiently access the virtual address anymore
08:34:30 <lava`> foreshadow (e.g. on the OS) is not mitigated by KPTI, because it doesn't care about virtual addresses
08:34:48 <lava`> it matches whatever is in the L1 or LFB, just based on the physical address
08:35:01 <lava`> even if the mapping is *not present*
08:35:14 <lava`> it still uses the phys addr field
08:35:55 <lava`> for fallout (overly optimistic store-to-load forwarding) it says "well the last 12 bits are the same, probably the entire address is the same"
08:36:20 <lava`> KPTI does not make any difference there
08:36:34 <lava`> because you don't even look at the page number any more or whether a page is present or not
08:36:43 <lava`> you just look at the last 12 bits and return whatever matches
08:36:48 <lava`> from whoever put it there
08:38:28 <Brnocrist> ah ok, makes sense.. it also works if the phys page is not shared with userspace?
08:39:32 <lava`> meltdown no, foreshadow yes, fallout yes, zombieload/ridl yes
08:40:34 <Brnocrist> yes, I am talking about zombieload :)
08:41:11 <lava`> yes
08:41:25 <lava`> we usually use fantasy addresses
08:41:29 <Brnocrist> ok, it was confused becase in variant 1 you do this assumption :)
08:41:30 <lava`> just the last 6 bits matter
08:41:41 <lava`> the rest is "rolling head over the keyboard"-style address
11:20:57 <doug16k> the core knows the physical address when it does an L1 access?
11:22:11 <doug16k> I thought it optimistically looked up virtually and used that, then later ensure TLB physaddr agrees with tag
11:23:14 <doug16k> or is this not L1 thing
11:24:39 <doug16k> lava`, ^
11:24:58 <lava`> well
11:25:00 <lava`> true
11:25:09 <lava`> but what if the access faults anyway?
11:25:42 <doug16k> so during that window between virtual lookup and checking tag you can side-effect the cache?
11:26:06 <lava`> the window is a bit larger, but, yes
11:26:16 <doug16k> wow
11:29:05 <adu> is this top secret fancy name vuln research?
11:29:38 <lava`> talking about things that went public today
11:30:17 <adu> zombieload?
11:30:37 <lava`> yes, and others
11:44:33 <doug16k> what's the signal to noise ratio for things as obscure as that virtual lookup issue? must be difficult to distinguish whether your load did the right thing at the right moment, right? :D
11:50:52 <lava`> well
11:51:13 <lava`> most of the time it's easy to distinguish noise from signal
11:51:20 <lava`> in these types of attacks
11:51:26 <zid> Presumably for things like that you end up with a sort of bimodal distribution of results
11:51:27 <lava`> but you need more runs
11:51:34 <zid> and you know what the 'real' result should be
11:51:47 <lava`> in meltdown for instance
11:51:50 <lava`> if the data is in L1
11:52:02 <lava`> meltdown leaks 500KB/s or more
11:52:24 <lava`> if the data is not in L1 but in L2/L3/LFB, it leaks 50-100KB/s
11:52:37 <doug16k> so you do the snooping from the other thread?
11:52:48 <lava`> no just the data has to be in the cache
11:52:50 <lava`> for meltdown
11:53:01 <doug16k> no I mean new one where you can read even with KPTI
11:53:05 <lava`> ah
11:53:20 <doug16k> how can you get that at just the right moment?
11:53:26 <lava`> for zombieload, we get also decent speeds, in some cases stable at 20-60KB/s
11:53:31 <doug16k> L1 is big enough for it to hang around?
11:53:40 <lava`> you just read as often as possible
11:53:47 <lava`> is the trivial approach
11:53:50 <lava`> the better approach
11:53:54 <lava`> is using a trigger signal
11:53:59 <lava`> to read at the right moment
11:54:13 <doug16k> ah watch a certain variable and when it changes right then is when?
11:54:21 <lava`> yes, and no
11:54:35 <lava`> usually you wouldn't see a variable
11:54:37 <doug16k> you'd have to do that with the same thing
11:54:42 <lava`> then you just do a cache attack for that part
11:54:43 <doug16k> ya circular logic
11:54:56 <doug16k> mine was
11:55:25 <lava`> so Flush+Reload for the trigger signal, then ZombieLoad, then exfiltrate via cache access, then Flush+Reload to extract the value, and then restart
11:55:51 <doug16k> isn't tons and tons of information missing?
11:55:57 <ZombieChicken> Discussing the newest hardware exploit?
11:56:45 <doug16k> I am trying to grasp the feasibility of getting anything useful when so much is aliased on the same place
11:57:23 <doug16k> lots of different addresses could optimistically hit right?
11:57:34 <lava`> sure
11:57:40 <lava`> but you can filter
11:57:44 <lava`> we call it the domino attack
11:57:51 <lava`> like the domino board game
11:58:24 <lava`> you start with one letter
11:58:30 <lava`> once you found a letter
11:58:34 <lava`> add one more
11:58:49 <lava`> like w, then ww, then www, then www., and so on
11:59:05 <lava`> you always use the part that you already have to find the new one
11:59:23 <ZombieChicken> Didn't it take the researchers half a minute just to get to the .com in the related URL (or whatever the TLD was)?