IRC channel logs

<stikonas>lain_: yes, but not the other way around. Anyway, at this point we don't really need to rely on DCC anymore, we have full source bootstrapping and if you want trusted guix environment, just bootstrap environment too

<stikonas>but if for example you have a whole bootstrapped system on a trusted hardware, and then have another hardware where you run the process you can still go one way only

<stikonas>if hashes mismatch then the other hardware is doing something dodgy

<stikonas>(though more likely your reproducible build is incomplete and got another source of non-reproducibility that you previously missed rather than hardware actually doing something dodgy)

<stikonas>on the other hand, if the hashes match, you can't say anything at all about 2nd machine being trustworthy

<stikonas[m]>pder: yes, I can reproduce the wrong checksum, I must have had something locally...

<stikonas[m]>I'll fix it now

<lain_>I see, ddc is only concerned with the package supply chain -which guix already makes very transparent stikonas

<stikonas>well, guix goes further than simple ddc (building with two compilers)

<stikonas>lain_: though guix does not bootstrap itself or guile or kernel

<stikonas>one could bootstrap guix program, guile and kernel separately

<stikonas>though you are basically stuck with these bootstrap binaries in guix anyway: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bootstrap.scm#n78

<stikonas>janneke (CC efraim): so after you said that guix updated to binutils 2.20, I was checking a bit how far tcc can take us (not with mes though). So binutils 2.30 can be built (and 2.30 does have riscv support). Possibly can go a bit further but it's getting harder and harder

<stikonas>and binutils 2.38 is not buildable with tcc

<stikonas>modern binutils are using more and more stuff that tcc does not support (i.e. uint64_t)

<stikonas>fossy: have you seen something like https://paste.debian.net/1272380/ before?

<stikonas>somehow kexec doesn't like newer gas

<stikonas>oh, actually looking at error message it looks like trying to build x86_64

<stikonas>maybe just --build passed o ./configure will help

<fossy>stikonas: how did you make binutils 2.30 work?

<fossy>stikonas: hmm, no, i haven't seen that before, but that is x86_64 *kernel* compat code, iirc, not architecture compat code

<fossy>since we assume i386 kernel (and it will be anyway soon when fiwix), it's fine to disable that if required

<stikonas>fossy: I've added lt_cv_sys_max_cmd_len=32768 to ./configure

<stikonas>I can push it to a branch

<stikonas>but checksums are wrong

<stikonas>and kexec fails

<fossy>lain_: my understanding is that yes, ddc can be applied to the environment

<stikonas>there were quite a few other problems

<stikonas>but they are fixed now

<fossy>nice

<stikonas>fossy: https://github.com/stikonas/live-bootstrap/tree/binutils

<fossy>i had a little bit of time to finish stripping yesterday, i'm just validating checksums in qemu then i'll push a PR

<fossy>it will be quire disruptive, because it updates nearly the entirety of sysc's checksums

<fossy>(we strip after file is available)

<stikonas>fossy: actually, with this binutis work, I noticed one thing

<stikonas>binutils can compress debug symbols

<stikonas>fossy: oh, maybe wait till binutils is merged

<stikonas>cause I had lots of checksum changes too

<stikonas>and also lots of commits...

<fossy>yeah, ok

<fossy>stikonas: what's wrong with kexec now?

<fossy>still same?

<stikonas>yes, same build error

<stikonas>purgatory/arch/i386/compat_x86_64.S:27: Error: unknown pseudo-op: `.code64'

<stikonas>hmm, maybe I need to pass some argument to binutils

<fossy>i'm not particularly convinced all this will fit in 4GB sysa...

<stikonas>to enable 64-bit support

<stikonas>how much does kernel use?

<stikonas>I checked before kernel build and we have loads of free memory

<stikonas>even after unpacking kernel but before building we have over 1 GiB left

<fossy>kernel uses about 800M in final step i think, when all .os are out and linking

<stikonas>I see, well, so far I had no problems...

<stikonas>i think I build the commit before binutils

<stikonas>and it worked fine

<stikonas>well, a lot of stuff like ed and bc are really small

<stikonas>and I wonder how come we didn't need them before

<stikonas>I guess bash 2 bug meant that we skipped some makefile rules

<fossy>yeah, that is a little od

<fossy>odd*

<stikonas>well, once we have fiwix, it might be easier with 4 GB limit

<fossy>yes, fiwix will effectively elimate the problem

<stikonas>and maybe newer kernel can also be built...

<fossy>it probably can

<stikonas>I've got rid of a lot of old stuff

<fossy>i think kernel version was limited by binutils before

<fossy>ill take a look at updating kernel after kernel work

<fossy>otherwise the ram problem will just become larger

<fossy>after kernel work = after builder-hex0/fiwix

<stikonas>yes, sounds good

<stikonas>fossy: maybe newer binutils can actually help with kerne stuff?

<fossy>it should

<stikonas>I mean not updating but space

<fossy>how so?

<stikonas> https://github.com/stikonas/live-bootstrap/commit/d90e140b4160cde1335aa9e5f692b9a02806515e#diff-58ec8e9d5d98f661a8c45ffdf5aa058cb6f01c495fbac25afce3a43fd05dc4c5R81

<fossy>quite possibly

<stikonas>large amount was probably debug data

<stikonas>so if it is compressed

<stikonas>we might actually have more free RAM than before

<stikonas>anyway, I'll try to pass --enable-64-bit-bfd to binutils

<stikonas>and see if that helps with kexec

<fossy>hopefully that doesn't break the kernel, i know you can't just indiscriminately strip vmlinux

<fossy>+1

<stikonas>unfortunately we won't be able to go the the very newets binutils...

<fossy>strange configure option name lol

<fossy>eh, this is reasonably modern at least

<stikonas>recent versions start using more and more C features that tcc does not support

<stikonas>yes, 2.30 is not that ancient

<stikonas>good enough for riscv bootstrap

<stikonas>so unless somebody needs loongarch, it should be fine

<stikonas>perhaps at some point tcc will also support more

<Mikaku>stikonas: Fiwix supports 4GB of virtual memory (3GB for user and 1GB for kernel), but this poses a limit to manage up to 1GB (aprox.) of physical RAM, no more

<fossy>i think there are much bigger problems with loong than binutils so far :P

<fossy>I don't think anything uses >1GB physical RAM?

<stikonas>Mikaku: but fiwix suports storage media, doesn't it?

<Mikaku>if you need more than 1GB of physical RAM, then you need a 64bit kernel

<stikonas>right now sysa in live-bootstrap is purely in RAM, and then sysc is using hard drive (or qemu image)

<Mikaku>stikonas: yes, no swap yet ;-)

<stikonas>that's fine then

<stikonas>initially we didn't know whether we will have storage support in bootstrap kernel

<fossy>i doubt we actually use >512MB RAM in sysa at the moment (perhaps Linux kernel linking is an exception?)

<fossy>(for compiling)

<Mikaku>as a reference point, I only need 256MB to build all FiwixOS packages in one shot, which include Python 3.6 and gnu-ghostscript as the bigger ones

<Mikaku>256MB of memory, I meant

<fossy>good to hear!

<lain_>stikonas my first statement wasn't fully thought out. It wouldn't need to, it would just need to be able to perform ddc within it and another environment. However, you told me that identical ddc results didn't say anything about the environment, so my point is void.

<stikonas>well, same as identical ddc results don't say anything about original compiler

<stikonas>e.g. maybe for some reason backdoor was not activated in this case

<stikonas>anyway, like I said before, now it's easier to think in terms of bootstrapping

<stikonas>where you control the whole chain

<fossy>why don't identical ddc results say anything about the original compiler? doesn't it gurantee that compile(compiler source, original compiler) = new compiler is non-malicious?

<fossy>if the backdoor isn't activated, then the backdoor won't propagate and it doesn't really matter

<stikonas>yes, it doesn't matter

<fossy>i agree that it's easier to think in terms of bootstrapping tho now lol

<stikonas>but I just meant we don't learn whether original compiler was completely good

<stikonas>though maybe as you say it doesn't matter

<fossy>ddc is still useful in some cases, i think

<lain_>stikonas it only guarantees that the initial compiler had nothing malicious added during it's compilation process

<lain_>it says nothing about the source code

<lain_>by "nothing malicious", I mean nothing self-replicating that would alter self-compilation

<lain_>ddc is useful because it allows you to verify the integrity of a downloaded compiler without having to do a full bootstrap, provided you have another compiler you already trust

<lain_>that was it's initial intention

<lain_>about the link you posted, that's very useful as it reduces the trusted computing environment to all hardware, firmware, running drivers, project source code, kernel source code, and kernel binary -chipping away to the light at the end of the tunnel lol

<stikonas>well, initially we didn't even have full bootstrap as an option

<lain_>does the guile bootstrap work now?

<stikonas>lain_: yes, but I think we only tried 3.0.8

<stikonas>presumably you could use 3.0.8 to rebuild prebuilt scheme files of newer guile

<lain_>nice

<lain_>how recent is that

<stikonas>I think 3.0.9 is the latest

<stikonas>oh, we can build 3.0.7

<lain_>I mean, how recently were you able to perform a guile bootstrap?

<stikonas>so 2 versions behind

<stikonas>oh, live-bootstrap does it every run

<stikonas>so like yesterday...

<lain_>that's awesome lol

<lain_>I love this community

<stikonas>guile is a dependency of GNU autogen

<stikonas>which is used to rebuild some machine generated files in GCC

<lain_>just found out that Microsoft Pluton firmware is in the mainline Linux kernel -so glad I use an operating system made by people who care about freedom

<lain_>the ultimate goal is to have hex0 as the only dependency, correct?

<lain_>only binary dependency*

<stikonas>lain_: well, there is also kaem-optional-seed if you want automation

<stikonas>and kernel

<stikonas>basically 3 pieces

<stikonas>though I think builder-hex0 kind of includes functionality of both hex0 and kaem-optional-seed

<stikonas>(maybe less flexible though)

<stikonas>but builder-hex0 is quite a big bigger, probably 3 or 4 KiB

<stikonas>lain_: if you trust your UEFI, you could use it to rebuild everything from hex0.efi though

<lain_>the process can be manually verified to be identical between just hex0 and hex0 with kaem. Once this is done, we have verified kaem is equal to the manual inputs, which makes the minimum hex0

<lain_>or that's how I see it

<lain_>the only way to verify hex0 is to read the machine code -but it's small enough that this is feasible

<lain_>you don't *technically* need a kernel, do you? Can't instructions just be passed directly to the CPU?

<lain_>I guess that's what we do with hex0, right?

<stikonas>lain_: you could, but then it's slightly different hex0 than in stage0-posix

<stikonas>that one uses linux kernel calls to open files, etc

<stikonas>we dot have hex0.efi that runs without kernel on top of UEFI

<stikonas>that one is somewhat larger than posix version but smaller than builder-hex0

<stikonas>lain_: https://git.stikonas.eu/andrius/stage0-uefi

<lain_>if stage0-posix can be built from hex0, the binaries you need to trust are still just hex0

<stikonas>kind of, though you still want to minimize amount of code written in hex0 language

<stikonas>hex0 is very painful to write read and modify

<stikonas>it's basically a commented out machine code

<stikonas>hex1 is much better

<lain_>you need the minimal amount of hex0 to get from a compiled binary small enough to read to something that can begin to automate the build process

<lain_>that's the most readable scenario

<stikonas>well, on UEFI, I could just go to my UEFI menu and run hex0.efi kaem-optional.hex0 kaem-optional.efi

<lain_>yes, but you have to trust all of those now

<stikonas>yes, but on amd64 machines you kind of trust it anyway

<stikonas>well, basically we just need a way to do input/output

<stikonas>on some other system, you could write a small driver in hex0 to do input/output

<lain_>you absolutely do, however the goal is to reduce what you have to trust as much as possible

<lain_>I'm just speaking in hypotheticals, certainly hex0.efi is a big step forwards from what we have now

<stikonas>well, then you can get PDB computer and use front panel switches to toggle hex0 into memory

<stikonas> http://dustyoldcomputers.com/pdp8/images-3C8F62C8/R00000254-hp.jpg

<stikonas>s/PDB/PDP/

<lain_>lol awesome domain name

<stikonas>oh, builder-hex0 also has a smaller bootstrap version that can build buidler-hex0 binary from builder-hex0.hex0

<stikonas> https://github.com/ironmeld/builder-hex0/blob/main/builder-hex0-mini.hex0

<stikonas>again, don't expect automation in that cae

<stikonas>case

<lain_>it doesn't need to be automated at that level, just reproducible

<stikonas>everything is fairly trivially reproducible at that level

<stikonas>it's harder to make it non-reproducible

<lain_>wow a 384 byte kernel seed

<lain_>that's impressive

<fossy>x86 is a bad architecture for trust, lol

<fossy>big fat binary blobs, opaque boot process, and ME/whatever AMDs version of ME is

<lain_>PSP

<fossy>last time i checked it out there was a big fat minix os running at highest cpu privilege on Intel

<fossy>yeah that one, escaped my name

<lain_>from 2008 onwards

<lain_>2006 on enterprise machines

<fossy>the name escaped me, that is :P

<lain_>:D

<fossy>i have a refurbished laptop from dell that has a sticker on it "ME Disabled", rather recent, i haven't ever been able to prove that the sticker is real though

<fossy>~2016 laptop iirc

<lain_>that's something they did for the NSA

<stikonas>well, ME can be supposedly crippled but not completely disabled

<fossy>well my locale is AU, wondering if it was returned from some government org possibly

<lain_>the ME is still present on your laptop, and still provides a key on startup (else your CPU won't boot), but "disabled" means it "promises" not to do anything else

<fossy>yeah, you cant get rid of the ME completely nowadays

<lain_>it doesn't matter where you're from, they added the "disabled" feature so the NSA could "disable" it from their computers lol

<lain_>or so I've heard

<fossy>ah

<lain_>yea, I think 2008 is still the last year it can be fully disabled for Intel

<lain_>2012 for like one AMD server

<lain_>speaking of ISA's, I just read that RISC-V explicitly supports the 2008 revision of IEEE-754 (floating point numbers) -the revision that introduced floats which use power 10 instead of 2, meaning they can exactly represent all decimals within their range

<lain_>Hardware on which the IME and AMD PSP can be fully removed: https://libreboot.org/docs/hardware/

<lain_>RISC-V: https://inst.eecs.berkeley.edu/~cs250/fa11/handouts/riscv-spec.pdf

<lain_>the 6th bullet in the introduction

<Zopolis4>apple is normally pretty good with TLA's, no?

<Zopolis4>does the M1 have any backdoor chip shenanigans?

<fossy>i find it unlikely, but apple isn't known to be particularly open, lol

<Zopolis4>i recall there were a variety of cases where apple refused to hand over user data or help the FBI crack iphones

<stikonas>yes, but that doesn't mean they don't have their own backdoors

<lain_>that was a long time ago, and tbh likely a pr stunt lol

<lain_>look up CSAM

<lain_>apple scans all your pictures -on both iOS and MacOS

<lain_>they added it in iOS 14.3 (as some reverse engineers found), started talking about it a few months later, claimed they would add it in iOS 15, there was massive backlash, "Oh sorry lol, guess we won't", and never removed it

<Zopolis4>oh im talking on a hardware level

<Zopolis4>like sure apple has all of my data on my phone

<Zopolis4>but i was considering getting Asahi on an M1

<Zopolis4>rather than waiting for the Power Notebook

<lain_>I mean, it's the same company

<lain_>I'm not aware of anything at the hardware level, but I wouldn't trust it personally

<muurkha>I am pretty sure that the RISC-V F and D extensions (floating point and double-precision floating point) do not require support for decimal floating point

<muurkha>lain_: can you link me to the information about iOS 14.3?

<lain_>muurkha https://libreddit.de/r/MachineLearning/comments/p6hsoh/p_appleneuralhash2onnx_reverseengineered_apple/

<lain_> https://github.com/AsuharietYgvar/AppleNeuralHash2ONNX

<lain_> https://forums.macrumors.com/threads/ios-16-csam-changes.2360117/

<muurkha>thanks!

<lain_>You're welcome!

<lain_>This was a big deal when it happened. People found collisions within around a day of the network being extracted, and I remember people would send the collisions to iphone users

<lain_> https://github.com/AsuharietYgvar/AppleNeuralHash2ONNX/issues/1

<lain_>^ first collision found

<oriansj>lain_: that is why I use a librebooted x200 running Guix

<oriansj>and why the next major project for me since the User space is being done beautifully by stikonas and fossy and the kernel work is being done well by rickmasters; is to start on the bootstrapping our own hardware.

<oriansj>(so if anyone wants me to buy them an FPGA system to help work on this problem, just let me know where to ship it)

<oriansj>(or if you need a computer to work on bootstrapping of software of any kind, please let me know)

<Mikaku>rickmasters: nice commit the one you pushed on ironmeld/boot2now

<Mikaku>rickmasters: I saw new constant names '-DCONFIG_MMAP2 -DCONFIG_64BIT_SYSCALLS' while building Fiwix, I guess we soon will talk about them ;-)

<rickmasters>Mikaku: Yes, there is a lot to talk about today.

<rickmasters>The big news is the completion of the first draft of kernel bootstrapping integration into live-bootstrap.

<rickmasters> https://github.com/fosslinux/live-bootstrap/issues/252

<rickmasters>I already see I have a lot of lint errors to clean up in my PR :)

<rickmasters>Mikaku: Here is where you will find all outstanding change to Fiwix to accommodate live-bootstrap:

<rickmasters> https://github.com/rick-masters/Fiwix/tree/fiwix-1.4.0-lb1

<rickmasters>I still plan on filing issues with explanations for the changes but feel free to take a look ahead of time.

<rickmasters>I should note that the kernel bootstrapping only works up to building Linux.

<rickmasters>There is still a final step to kexec/boot Linux that I will be working on next.

<bauen1>rickmasters: that looks interesting, seems like I need to get back into osdev ... perhaps write a builder-hex0 clone in arm for my pine a64 board, after all it has an easy enough UART driver to implement ...

<bauen1>I really need more time in a day ...

<rickmasters>bauen1: yes, ports to other architectures are still needed. builder-hex0 shows what functionality needs to be there for bootstrapping up to tcc.

<bauen1>rickmasters: how useful would be actual drivers instead of relying on the BIOS ? e.g. a tty driver using the VGA Framebuffer would be relatively straightforward, a read-only / read-write hard disk driver a bit less

<rickmasters>bauen1: live-bootstrap runs without graphics so it would be a serial port driver I think.

<rickmasters>bauen1: using the BIOS for "console" output supports screen output on hardware AND allows qemu to redirect that to text output as well.

<rickmasters>bauen1: but I haven't put a lot of thought into other options. BIOS output was the easiest because it was common in tutorials I found when starting out.

<Mikaku>rickmasters: I'll take a look to these list of changes: <https://github.com/mikaku/Fiwix/compare/master...rick-masters:Fiwix:fiwix-1.4.0-lb1>

<fossy>rickmasters: this is very exciting! i'm reviewing that shortly

<fossy>first i'll review binutils 2.30

<stikonas[m]>fossy: I can add copyright year though current suggestions are not to change it afterwards https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code

<fossy>stikonas[m]: ok, that sounds fine to me

<fossy>tbh, at the end of the day, it's likely rather inconsequential, but maybe let's just follow https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code#tldr this format

<fossy>whoever wrote this appears to know what they're talking about

<stikonas[m]>bauen1: I guess it would be sufficient to just implement read only device input on systems without BIOS, though you won't have an easy way to debug issues unless you also have some output, e.g. console

<stikonas[m]>And then have more stuff in 2nd kernel

IRC channel logs

2023-02-28.log