IRC channel logs
2023-06-20.log
back to list of logs
<fossy>stikonas: oh that's pretty cool :D <stikonas>I wasn't able to produce fully static binaries with it yet, it dynamically links to glibc... <stikonas>probably it's possible to fix that with LDFLAGS="-static" but then I need to build musl and static python... <stikonas>it's also noticably faster than cpython programs <fossy>that's not overly surprising, given that python is interpreted haha <kerravon>it just occurred to me. do you really need to start the bootstrapping process by entering code and writing it to disk? isn't it enough to simply enter enough code (via whatever method deemed safe) to simply VERIFY that the hex on the disk is correct before executing it? <kerravon>oriansj - with regards to 386 DOS - how do you intend to access the INT 21H DOS functions? will you be using a DOS extender in protected mode and using the DPMI interface? <kerravon>once you start adding a dos extender, you may as well add the HX dos extender <kerravon>and can the bootstrap be done from a pressed cdrom, using a microscope to verify the pits in the boot sector are the expected hex? <kerravon>i was wondering if it would be useful to have the firmware using a 68020 processor to read x86 code from the cdrom, but i don't think that buys anything <kerravon>i'm not sure how anything can be considered secure when the bios is a black box <kerravon>i guess seabios could be flashed from the cdrom at the beginning of the process <kerravon>and then at the end of the mostly-automated process, seabios is built and compared to the original that was flashed <kerravon>so long as you trust the flashing process <kerravon>i think after verifying the sector c binary is on the cdrom, you need to have it display a c program, and ask the operator to hit enter, and then i think the rest of the process can be automated if you are happy to rely on md5 signatures <kerravon>actually it's not just relying on the md5 signatures. you can verify that sector c has generated the executable that is already on the pressed cdrom <kerravon>ie your first sector c program can do that verification <kerravon>hmmm. i think you still need to read each source file, as well as doing the md5 check of the source, before doing the generated binary comparison <stikonas[m]>Well, nobody here claims to have solved BIOS or hardware bootstrap process <stikonas[m]>But those are the most common machines on the market <stikonas[m]>You'll never be able to recreate Intel or AMD processor at home <stikonas[m]>So for these machines assumption is that HW/FW is trusted <stikonas[m]>If you don't trust them, you need a different hardware, I.e. maybe RISC-V... <stikonas[m]>Though RISC-V dies not guarantee that hw is trusted either <stikonas[m]>But I guess even if you flash seabios binary, rebuilding the same binary does not rove anything <[exa]>kerravon: "secure" is always relative to the amount of paranoia you're willing to invest <roconnor>I'm assuming the firmware in my hard drive is just using DMA to overwrite my working memory with trojans all the time. <kerravon>stikonas - it's not perfect, but if I build the seabios binary on an unrelated machine (that doesn't even use seabios), and burn (or better - commercially press) a cdrom, and go to another machine and flash seabios, and the flashing process is at least trusted, and then rebuild seabios on the new machine, then it would be very difficult for a <kerravon>trojan on the non-seabios machine to make it across <stikonas>unrelated machine might have gcc with trojan <stikonas>is that really any more difficult than trojan propagating in e.g. kernel? <stikonas>but it's difficult for backdoor to propagate via kernel too <kerravon>well on the new machine, the trojan in the bios needs to detect that gcc is running and reinsert itself into the new seabios binary <stikonas>and I agree with you that it's hard in practice (as is any self-propagating attack) <stikonas>but I dont think it's much harder than propagating via kernel <kerravon>sorry - the kernel will be covered by building starting from hex, right? <stikonas>there is userspace bootstrapping that starts with userspace hex0 builds hex1, hex2, M0, cc_x86 (or other arch) and M2-Planet <stikonas>and there is this new path that starts with builder-hex0-stage1 <stikonas>which kind of includes similar functionality as hex0 but also knows some BIOS calls to act as a kernel <stikonas>and then it can bootstrap more complicated kernel <stikonas>that can run the rest of userspace bootstrap chain <stikonas>(but this kernel bootstrap so far is only done for x86) <stikonas>but let's say you are on non-x86 platform where we don't have kernel bootstrap chain <stikonas>then you need to start with some pre-compiled kernel <kerravon>just cross-compile it from the trusted x86? <stikonas>above let's you trust kernel and userspace <stikonas>but maybe you don't trust hardware itself <stikonas>(though ME and PSP I guess are FW, not HW) <kerravon>but maybe you trust them more than the new machine? <stikonas>what is your attack / secucity / trust model <stikonas>which will be different for different people or situations <kerravon>i guess if the new machine is trojan-free, then building on the x86 may introduce a trojan from the firmware <kerravon>and if the new machine has a trojan, then bringing across something from the x86 won't help anyway <stikonas>but you could imaging that hardware itself has a self-propagating trojan <stikonas>i.e. hardware infects software synthesis tools for HDL <vagrantc>ACTION waits for the paper tape readers to get dusted off <kerravon>how will a paper tape reader bypass a firmware trojan? <vagrantc>well, any respectible platform allows you to build the firmware from source ... <vagrantc>if it's not hardware, it's software, so bootstrap it :P <vagrantc>and then, of course, bootstrap your hardware is the next logical step <kerravon>but why is paper tape better than a cdrom? <vagrantc>more feasible to implement from scratch? <vagrantc>my eyes aren't good enough to read CDROM media <vagrantc>and my hands are not precise enough to create a CDROM, really... <kerravon>you only need to use a microscope to read the boot sector of the cdrom, and then you can view the source code of the next thing to be compiled <vagrantc>not sure how long it would take you to review a 650MB CDROM with a microscope ... but i am guessing it would take a good long while. <kerravon>the rest can be done on the screen in hex or text <vagrantc>infinitely, but i am not sure any of us have the time. <oriansj>well once one includes the problem space of the Nexus intruder class attackers, no hardware you didn't build yourself can be trusted and even then perhaps not even then if grey goo is included in the problem space <vagrantc>i can write paper tape with a sharp implement and, well, paper. and read it with the naked eye. <oriansj>once matter compilers are invoked, we enter a very hard to debug problem space <vagrantc>the most complicated thing there (if you take the biological evolution of the eye and consciousness and whatnot) is probably paper <vagrantc>and then, of course, the paper tape reader ... <kerravon>sorry - the paper tape reader - are you trusting the machine built by someone else, as well as the computer firmware? <oriansj>kerravon: I am open to building my own <kerravon>but you can't build your own cdrom reader? <oriansj>kerravon: I can't build my own floppy drive yet; but that probably has to do with my ability to build physical objects at the needed tolerances <kerravon>a floppy drive can't be visually inspected <vagrantc>without complicated industrial infrastructure <kerravon>if you only need to inspect the boot sector <oriansj>kerravon: magnetic paper can be used to inspect magnetic media <vagrantc>kerravon: what is the highest magnification microscope you have ever built? <oriansj>kerravon: well optical microscopes with no software or cameras involved are probably fine (as long as matter compilers are not invoked) but microscopes with cameras and running software are perhaps a different matter <vagrantc>anyways ... you can always go another layer deep ... that is all i'm getting at <kerravon>yeah, i'm just talking about a good quality microscope <vagrantc>but of course oriansj is taking it to the molecular and/or atomic level already :) <kerravon>and you probably want to put a long run of 1s then 0s, then 1s, after the boot sector, so that you know where it is <vagrantc>this takes off-by-one errors to a whole new level :) <kerravon>oriansj - did you see my question about DOS? <oriansj>Each pit is approximately 100 nm deep by 500 nm wide, and varies from 850 nm to 3.5 µm in length so possible assuming the 3.5 µm long pits <kerravon>the microscope will just show a blank area for the 850 nm zeroes? <oriansj>in regards to your DOS question, I had not expectations as I was exploring the possible task of starting the support of DOS in M2libc and am not familiar with DOS programming enough to have preferences yet. <kerravon>sure - but are you happy to use a dos extender? <kerravon>since you are happy to be 80386-specific <oriansj>kerravon: and you'll have to guesstimate the length of zeros and hope you don't have off-by-one errors <oriansj>kerravon: provided one exists under an FSF approved license or can be achieved in Free software DOS implementation. <kerravon>ok, HX is currently just advertised as "freeware" <kerravon>there is a github issue asking for that to be expanded <kerravon>assuming that is expanded to be FSF-compliant, you are apparently happy to use it - in which case, you can just use win32 <kerravon>and if you just use win32, you can probably just use pdos/386 <kerravon>depending on what you are trying to achieve by "dos" <oriansj>well yes a Windows (ReactOS) port of stage0 is definitely a possibility in the future if we find someone who wants it enough to do that work. <kerravon>and you're happy to do that instead of whatever "dos" means? <oriansj>as stage0 will support any platform and/or architecture which someone has a desire to do the work required. As the more we have, the harder time any attacker will have; as they will have to compromise *ALL* of them in the same way to prevent detection. <kerravon>so you currently don't have windows support in m2libc? <oriansj>kerravon: nope, too unimportant of a target and no one cared to put the effort in yet. <oriansj>a couple people have worked on DOS ports in the past but none of them felt comfortable sharing their work <oriansj>getting a half complete start should inspire further progress <kerravon>i'm talking about your interest. you wanted help doing a dos port. but actually i don't really know what that means, unless you're talking 16-bit <kerravon>once you add a dos extender, you may as well call it HX or Win95 <kerravon>there are a lot of dos extenders to choose from <oriansj>kerravon: my interest is purely in helping others openly cooperate <kerravon>ok, well i can't help you (with pdpclib to be put into m2libc) if you aren't clear on requirements. <kerravon>so i guess that means no public domain cc_x86 <kerravon>actually - if it isn't using cdecl anyway, it's probably not of any use to me <kerravon>i'll get back to you if i have a specific use for it <kerravon>we are expecting other compilers to get to c90, and we already have a subset of c90, and it uses cdecl <kerravon>how about a cdrom where the boot sector says "press space to boot, ctrl-c for bootstrapping verification"? <kerravon>or maybe hold down shift and it switches to bootstrap verification <kerravon>with regards to pits on the cdrom, maybe x'ff' can be added to the boot sector(s) to help with reading via microscope, for syncing