<Hagfish>"Through a combination of in-house engineering projects, targeted investments, generous grants, and multi-media public education efforts, we will free technology from the control of the few and recreate the spirit of freedom, innovation, and self-reliance that underpinned the American tech industry only a few decades ago." <oriansj>well I think I managed to make negative progress <oriansj>it is hanging on the fout->write(fout, &size, &output_buffer); <oriansj>he doesn't care at all; sounds like uefi to me <oriansj>although I also get: ./efi/file_protocol.h:15:46: warning: implicit conversion from 'unsigned long long' to 'uint64_t' (aka 'unsigned long') changes value from 9223372036854775808 to 0 [-Wconstant-conversion] so it might be related if the create bit isn't being set but it also doesn't overwrite files that exist either so... puzzle <stikonas[m]>And if we go for mes later, we might need it there too <stikonas[m]>Though for makefile maybe it's better to search over all candidate paths for ovmf ***Andrew is now known as HaxCPU
<stikonas>oriansj: I'm looking at you makefile changes <stikonas>which would be a bit strange as kvm is used widely, including in live-bootstrpa <vagrantc>kvm in various forms is definitely present in debian ... <vagrantc>although the kvm package was merged into qemu quite some years ago <stikonas>well, location of OVMF_CODE.fd is different, so I guess Makefile should look in both places <bauen1>i don't think you want to run live-bootstrap without kvm, that just makes it take even longer <stikonas>yes, it would be taking a day instead of 2h <stikonas>hence I was adding -enable-kvm option in stage0-uefi too ***stikonas_ is now known as stikonas
<oriansj>stikonas: well currently kvm is off for me; I'll probably turn it back on in the future but it isn't on at this moment. <stikonas>well, so far I pushed in OVMF path change <vagrantc>oriansj: you turned it off in the hardware? <vagrantc>oh wow, stage0-uefi ... this is getting exciting! <stikonas>I just started reading about it last weekend <oriansj>vagrantc: well in my libreboot firmware <stikonas>oriansj: ideally we would enable it by default but let turn it off in makefile <vagrantc>oriansj: stability issues? security issues? <oriansj>stikonas: well a variable would make it simple <stikonas>QEMU_KVM = -enable-kvm and then you can run with make QEMU_KVM= <oriansj>vagrantc: there is a security reason for it at this momement but generally it is a very useful tool. <stikonas>oriansj: do you want to make a merge request or should I push it myself? <oriansj>stikonas: I'm still playing here to get a feel for uefi, so please don't let me stop you <stikonas>I also still need to look at your other changes <stikonas>I was thinking about it, but I'm not sure if it's worth doing it for hex0 or hex1, maybe for hex2... <oriansj>stikonas: no, I was trying to figure out the read/write behavior for UEFI <stikonas>since I think it would end up in more instructions <stikonas>I have done a lot of tests before I got it to work... <oriansj>as I noted a weird thing when I tried to writes, it would just hang <stikonas>yeah, that's the problem. It's hard to debug... <stikonas>I think it might be possible to wire in gdb, but it's not trivial <oriansj>so there is something I am missing with writes that is important, I just don't know exactly what it is yet. <stikonas>so I was mostly debugging with return codes... <oriansj>I added a function to print debug statements <stikonas>but yes, I had some issues too with buffers <stikonas>but eventually I decided to switch to single byte reads/writes <stikonas>possibly because then I don't need to allocate memory <stikonas>all those function calls have quite a bit of overhead <oriansj>well allocating in uefi doesn't look much worse than brk/malloc <stikonas>but in hex0 in posix we also don't allocate <stikonas>well, e.g. I did open_protocol function call yesterday <vagrantc>UEFI would be an interesting target as there are multiple implementations all over the place ... so even if you're using an "untrusted/unbootstrapped" UEFI, if you can build reproducibly starting with other UEFI implementations ... you can gain some reasonable confidence there <stikonas>well, it's interesting in the sense as a lot of x86_64 hardware runs it anyway <stikonas>so even if it's unbootstrapped or untrusted, you kind of have to trust it anyway if you want to run anything on that machine <oriansj>unless you are on a coreboot/libreboot system <qyliss>Coreboot is usually used to boot UEFI <stikonas>although, I guess you can use some UEFI as payload <oriansj>qyliss: well yes, UEFI becomes just another payload like grub <stikonas>on rockpro64 I have U-boot which implements UEFI... <stikonas>anyway, it was somebody in this channel that mentioned UEFI last week <stikonas>and then it just started going. Well, I guess for now it's mostly me and oriansj looking at this <oriansj>stikonas: that would be rickmasters and you know me, I'm always down for the new playgrounds <stikonas>oh yes, rickmasters was also curious about this <stikonas>though he was not sure whether he'll find enough time <oriansj>yeah, time is a rare supply these days <stikonas>now i need to fix kaem not to timeout... <stikonas>oriansj: do you think kaem is sufficient? <stikonas>i.e. hex0 or hex1 definitely shouldn't run for 5 minutes... <oriansj>stikonas: well only kaem and the pieces that are after m2libc would need to worry about that <stikonas>well, I guess m2libc initialization can call it... <oriansj>well i was thinking about M2libc a bit yesterday and we can hide all of the UEFI stuff behind the libc.M1 and a single platform file <stikonas>oh ok, I haven't thought too much about it yet, I was assuming we would need to use ifdefs and also special directory (similar to linux directory that we have) <oriansj>so instead of just: CALL_IMMEDIATE %FUNCTION___init_io we can do a CALL_IMMEDIATE %FUNCTION__UEFI_init or something like that <stikonas>oh and we have one more thing to think about <oriansj>you mean the passed arguments? or the utf-16 bit? <stikonas>so first 4 arguments go in rcx, rdx, r9 and r10 <stikonas>but you also need to leave a space on the stack for the first 4 arguments <stikonas>and if one of the first 4 arguments is too bug (more than 64-bit) then it also goes onto stack <oriansj>the M2libc ASM blocks might get a little ugly but that isn't much of a problem <oriansj>even if every syscall/uefi call had a completely different calling convention, the fact that our bedrock functions are fully self-contained gives us a boatload of flexibility <stikonas>well yes, this whole uefi-port would be that difficult in the end <stikonas>we need to replace syscalls, figure out binary format <stikonas>but lots of other stuff could be reused from stage0-posix <oriansj>wall clock for stage0-posix-amd64 from hex0 to done is: 1:37.54 so yeah kaem-optional and only the C programs using M2libc need to turn off the timer <stikonas>well, kaem-optional needs it in any case <stikonas>because if somebody builds on top of it, say mes <stikonas>then eventually we would exceed 5 minutes in kaem-optional-seed <oriansj>definitely will be running for a potentially very long time <stikonas>in live-bootstrap it keeps running until we reboot into a new kernel <stikonas>I think you need to stop uefi boot services <stikonas>not a problem, but some function calls will have to be done <oriansj>but something we can deal with later