IRC channel logs
2020-02-14.log
back to list of logs
<fossy>markjenkinswznc: thanks, this is super helpful <fossy>markjenkinswznc: this is precisely the idea <OriansJ>and why I wrote kaem-minimal.hex0; to help fossy have a smaller bootstrap <OriansJ>xentrac: it is the goal of Knight's hardware implementation to rule out any lithography based attacks (Such as the nexus intruder program class) <OriansJ>I believe the phrase is there is no kill like overkill <OriansJ>xentrac: because CMOS processes do not have manual mask generation processes these days <xentrac>well, TTL processes don't have any mask generation processes at all these days <OriansJ>xentrac: true to a degree; plus manufactor of TTL circuts in one's garage is much easier than a 2K transistor chip <xentrac>you can definitely make a 2K transistor TTL chip <xentrac>or a 1-transistor CMOS chip, such as a 2N7000 <xentrac>I don't mean in your garage necessarily <OriansJ>Well the idea is anyone with access to 1950s level technology should be able to independently reproduce everything to make any attack vulnerable to detection <xentrac>TTL doesn't really have a hard limit on how many transistors you can put on a chip, and there have been ECL CPUs with many millions of transistors <xentrac>so you could probably do the same thing with TTL <xentrac>people don't because CMOS gets faster when it gets smaller and TTL doesn't <xentrac>I mean, it does, a little. but not like CMOS <xentrac>(TTL has parasitic capacitances too, after all) <OriansJ>fair; and the point of TTL as a goal is less about process and more about level of public review. An gate level schematic that can be built out of individual gates or as a single CMOS chip to reproduce the results <OriansJ>Thus there becomes no attack any nation state can perform that could compromise the bootstrap binaries <OriansJ>as anyone in their garage would be able to make their own chips and detect such a scheme <xentrac>if you wanted to maximize the ease of hand assembly, you could use RTL <xentrac>once you're working in ICs it has very little advantage though <OriansJ>xentrac: I'll keep that in mind, when I go to doing the physical implemntation. <OriansJ>But first I need to finish the GCC bootstrap via mes-m2 <OriansJ>Should one switch them to generate an idealized intermediate architecture as a target, it enables shared optimizations to occur across all architectures and a single per architecture specializer (that can be shared betwen them) which becomes the only work needed by them to be ported to new host architectures. <OriansJ>but that is just a crazy idea of mine to break the scheme bootstrap problem in half and have guix bootstrapped from a single scheme compiler. <dddddd>I was reading about GENERIC and GIMPLE just a few hours ago! <OriansJ>dddddd: hard to say but they are the first C compiler to aggressively exploit it <xentrac>no, no, lots of compilers used intermediate representations <xentrac>the Dragon Book has a chapter or two about them, and it was published in 1977 <dddddd>Yeah, kind of remember that, so "gcc trick" surprised me a bit. <xentrac>well, GIMPLE isn't really an idealized intermediate architecture... <xentrac>I mean there are lots of kinds of IR and most of them don't look very much like CPU instruction sets <xentrac>(although of course you could implement any of them in hardware!) <OriansJ>Hence why GCC was the first to aggressively exploit it (more optimizations than anyone!) <OriansJ>xentrac: ok, might I ask what compiler had more architecture independent optimizations prior to GCC? <xentrac>I guess it depends on which point in GCC's evolution you're looking at. there might even have been times in GCC's evolution where the answer was "nothing" <xentrac>right now I think the answer is probably "portland group C"; 25 years ago probably "CenterLine"; when GCC was initially started probably pcc <xentrac>(and any other portable C compiler, maybe VUCK's C compiler, but there weren't that many around at the time) <OriansJ>xentrac: you might be entirely correct as I honestly never heard of those compilers before <xentrac>you just mentioned pcc yourself, although I think you might have meant 1983 rather than 1973 <dddddd>That started the rabbit hole path to GENERIC and so... <xentrac>heh, there's a postscript to the announcement by Tower <OriansJ>stupid idea, could linux v1.0 be converted to M2-Planet C in a reasonable amount of effort? <Hagfish>"In the future, it may be necessary to increase the level of confidence in this validation, which could prompt the need for a "simpler" and more verifiable reimplementation of rustc" <markjenkinswznc>OriansJ, Ur-scheme is a nice find. If it has a great test suite like it says, that's super, even without, interpreting it with mes-m2 and seeing if it can reproducibly recompile itself is a good sanity test, a good test to pass before interpreting mescc to compile mes/mes-m2 into a reproducible stable-mutual self-hosting loop <janneke>OriansJ: yes that's interesting, in a way i can't wait till the time we can worry about those things and play with them *janneke just booted first home-built linux on the pinebook-pro <pder>I am trying to troubleshoot an apparent bug in mes-m2, but I am new to scheme. <pder>(member (list 'a) '(b (a) c)) evaluates to #f but it should be ((a) c) <pder>Oddly in mes-m2 (equal? (list 'a) (car (cdr '(b (a) c)))) evaluates to #t <fossy>OriansJ: I would really appreciate it if you could look at BeeOS <fossy>It seems to be a reasonable target that with minimsation and conversiton to m2 planet could likely be a target for our kernel work <fossy>heres the other one that looked super good <OriansJ>pder: looks like an interesting bug for me to fix <OriansJ>pder: nope, looks like I just screwed up the member definition <OriansJ>it is supposed to (member i (cdr l)) and I wrote (memq i (cdr l)) <pder>Ah ok, I was looking in the wrong place. Looks like memv has a similar bug calling memq <pder>I was looking at mes/module/mes/scm.mes but that does not seem to be used yet <OriansJ>nope as I haven't yet figured out modules <OriansJ>and patch is up (with a prototype for case statement support in mes-m2) <OriansJ>fossy: there are alot of POSIX kernels out there; the really important question is which of them are willing to collaborate with us. <OriansJ>fossy: as basically any POSIX which has a free (as in freedom) License and an interested developer(s) [multiple are of course preferred] will work. <OriansJ>The problem is finding them, getting them to engage and hammer out any bugs in getting mescc-tools-seed+above running on them. (as after we get GCC running, we can just compile linux and be done) <OriansJ>if the title wouldn't get me hellbanned; I would be so tempted to post "stage0 project seeks kernel developer(s) for hot bootstrapping action" just to try to get someone to help with that work