IRC channel logs
2021-12-29.log
back to list of logs
<stikonas>although, if you need python later in your system, you'll still have to build it. <stikonas>it's probably from 2.27 or something like that <muurkha>although that does rely on the BIOS to set the video mode <stikonas>well, one one hand none of that is available on ARM <stikonas>on the other hand, ben eater's VGA card only has one mode <muurkha>yeah, if you're designing your graphics hardware yourself, you can choose to make it easier to initialize <doras>We really should download it from a more reliable location... <muurkha>not sure how complex setting the mode by hand is even on the VGA. I'm guessing it's about six instructions <doras>Oh wait, it's not available in https. <stikonas>and I suspect fossy also has a copy somewhere <stikonas>but it's on my home network, so only 18 Mbps upload <doras>GitHub/GitLab + Git LFS works great for mirroring tarballs, by the way. <stikonas>most of the tarballs are from GNU FTP mirror network, so are fairly well mirrored <bauen1>muurkha: the challenge is having a trusted input/output peripheral, if you have that and a trusted cpu (with e.g. signed boot support and a little bit of secure storage) then if you trust your hdd / network adapter / other peripheral doesn't matter anymore <stikonas>well, software heritage can't find flex 2.5.11 <muurkha>bauen1: it does become a problem in many fewer circumstances, yes. you don't even need the trusted I/O for many applications if you have signed boot and secure storage for keys <bauen1>muurkha: true, you only need trusted I/O if you're talking to a human, if you're talking to another computer then untrusted I/O (i.e. network) is usually enough ; but for bootstrapping you want some trusted I/O <bauen1>but then actually getting a cpu you can trust is incredibly hard, basically impossible, so that probably shouldn't be your biggest worry <muurkha>yeah, if you want to use the computer to look at your source code <muurkha>I don't think it's that hard, it'll just take a few years of effort <muurkha>and you might be able to use existing microcontrollers <bauen1>there's also this guy making ICs in his garagae, iirc he's up to 1000 transistors per chip, which should be enough to build a simple CPU <muurkha>I haven't been able to get a transistor CPU design much below 3000 transistors, and then you need some kind of RAM <bauen1>in theory you don't need too much ram if you can do authentication fast enough, then you could use some off the shell untrusted SRAM <doras>It seems they have a tag for 2.5.10, but not 2.5.11 <stikonas>I can find exact commit needed on gio's repository <stikonas>actually this is with a few patches that we apply manually in live-bootstrap <stikonas>506e9605baf4638ba47d37133c348df1385ef06c <muurkha>bauen1: you probably need at least 1024 transistors of RAM, more likely 8192 <muurkha>I mean maybe there's a secure way to encrypt off-chip RAM that doesn't need that much memory? I don't know of it <bauen1>muurkha: wikipedia says 6 transistors per bit, so i assume much of that will also go to decoder logic ? <bauen1>muurkha: you'd need authentication not encryption, but that probably doesn't make it much easier <bauen1>or well, if you eventually need encryption then you'll need another 256 bits for your private key and whatever temporary storage you need ; that doesn't need to be very fast <muurkha>6 transistors per bit would make 64 bytes (512 bits) 1536 transistors, but that's SRAM; dynamic logic schemes can often manage less, and are a good fit with the bit-serial processing I applied to get Calculus Vaporis down below 3000 transistors (at a ruinous performance cost) <bauen1>muurkha: i see i messed up bits / bytes once again <bauen1>muurkha: looks like OPTEE uses 1 sha256 hash per 4KB of memory, so for 4MB of external memory you'd need 32KB of trusted RAM, a few KB of cache and a fast sha256 implementation (either done by the CPU itself or implemented in hardware) <muurkha>yeah, as your cache drops below 4KiB that would get inefficient fast :) <muurkha>right, and you don't need a GPU, just some kind of framebuffer <muurkha>a J1A might be smaller and more verifiable than RV32 <muurkha>but if you're spending 6 million transistors on SRAM it doesn't matter that much whether your CPU is 10k transistors or 100k, even if you want to verify the transistors and the CPU transistors are more difficult to verify <bauen1>muurkha: i mean the end goal would probably be a trusted CPU and trusted peripherals (basically UART I/O) and a system that is fast enough to compile the linux kernel + gcc (i.e. bootstrap) in a reasonable time span, where that time span is probably anything less than 1 year <muurkha>1 year is fine once it's debugged, but it would make debugging it impossible <bauen1>muurkha: there's imo ways to reduce the need for debugging: isolate hardware components and keep them simple (i.e. no fancy prefetching etc...) as much as you can get away with it, it will make it easier to verify and means less debugging ; you have untrusted but very fast computers available that can be used to run simulations of the cpu, probably much faster <muurkha>but at some point you may have to figure out which instruction in the hardware doesn't work reliably <stikonas>doras: thanks. Let's see if the tag appears <bauen1>you'd probably end up going a middle way, build your own architecture and then write an rv32 emulator (which can be extensively tested on a fast computer), that way you have a simple architecture that is relatively fast and comparatively easy to verify, but can use a bigger ecosystem already available <bauen1>muurkha: that's true and that will be an absolute pain <fossy>unfortunate about flex, i was hoping this wouldn't become a problem for a little while :\ <fossy>hopefully we do get a response on github <bauen1>muurkha: the real problem will probably be figuring out the sweet spot between too many transistors and too slow <bauen1>nevermind any manufacturing defects <stikonas>well, at least not on that mirror, I have https on my server <fossy>but link rot is a thing i was hoping wouldn't really happen <stikonas>yeah, so far we only had it with linux-libre <stikonas>but it works after we moved to /old/ subdirectory <stikonas>fossy: by the way, I've just noticed that old perl configuration files still point to /image directory <stikonas>oh, it's actually only version 5.003 that has in wrong <stikonas>so shouldn't be too hard to fix, probably just 1 run of live-bootstrap to get checksums out <stikonas>fossy: also, I think things might be a bit simpler (from preparation perspective) if we rename /after directory as /sysa <stikonas>that might make running live-bootstrap without rootfs.py a bit easier <stikonas>as for sources, I think we can put leave all sources in /sources directory and then have a kaem script to move them into correct locations... <stikonas>it's a tiny bit more annoying from the development perspective (need to maintain list of sources in two places) but would remove even more of rootfs.py <oriansj>muurkha: actually if one makes the RAM 1x64K and uses 4096 of them; 32MB of RAM which only gets 1 bit per 4Kb of memory. then auditing of the RAM chips becomes a non-issue. <muurkha>oriansj: because when you've seen one chip, you've seen 'em all? <oriansj>bauen1: if you do AArch64 bootstrapping on bare metal, it is something that stage0 proper would want to include (if you are interested of course) <oriansj>muurkha: there is no way for a RAM chip to know which bit it would be altering in 4K <oriansj>nor would it know which 512byte page of memory it was <muurkha>sort of similar to bunnie's "FPGAs are safer" argument <oriansj>muurkha: for various values of safe of course <oriansj>not safe from a nation state having a remote disable all power functionality baked in <muurkha>(though the KKK would like to turn the US into a nation-state, they have so far been unsuccessful, and the trend has been very much in the opposite direction) <oriansj>muurkha: well the US isn't actually making most chips these days and I am not sure if China could be considered a Nation state either. <muurkha>hmm, I think the mythology of Han ethnic identity is pretty strong in PRC nowadays <muurkha>and underlies things like the Uighur concentration camps <oriansj>muurkha: so I retract the term nation state and replace it with just government to truncate the non-bootstrap related part of the conversation. <fossy>stikonas[m]: do you mind if we wait until i finish packaging to do those restructuring things? <fossy>it shouldn't be too long until i finish that <fossy>i agree with those restructures generally though <nanonyme>Hmm, is it intended timestamp reset code tries to reset timestamps also for /proc? <stikonas>don't remember who wrote that code, but it wasn't fossy or me <nanonyme>Ack. I'm for now discarding the parameter, it will not really work if live-bootstrap is run rootless and user won't have permission to mutate /proc <nanonyme>stikonas, I see there also is no cc binary (symlink to gcc). Is this intended? <stikonas>nanonyme: we probably juts didn't need it <stikonas>all configure scripts that we used simply worked fine with gcc <stikonas>and if make install didn't create it, then we don't have ti <stikonas>nanonyme: are you building something that needs it? <nanonyme>stikonas, yeah, I don't remember which part of bootstrap requested it. We're building GCC+glibc toolchain <nanonyme>I can flush build cache and try again later. I've been currently focusing on getting stage1 GCC built, seems problematic <nanonyme>I'm basically trying to build a binary image that would make it simpler to build further toolchains for our distro <stikonas>nanonyme: well, either add symlink manually in live-bootstrap or in your further scripts <nanonyme>Yeah, no big deal. I'll add it in the further scripts <nanonyme>GCC9+glibc2.68 is currently the target goal, that is latest combination we have been using which doesn't require Python to build glibc <stikonas>nanonyme: if you use ln, I guess use -f argument in case symlink appears in live-bootstrap at some point later <stikonas>well, GCC9 is almost the newest you can hope to go in one step <stikonas>GCC11 already needs newer C++ standard, so is definitely not buildable with GCC 4.8.4 <stikonas>i simply meant that GCC10 is the newest version you can jump to in one go <muurkha>oriansj: sorry to be so prone to go off on tangents