bvt's backtrace

To start off, the previous item on my schedule was speeding up multiplication routines of FFA by providing their assembly versions. So far I consider this piece of work done. If someone reviews the code and discovers an opportunity for optimization or any other improvement - I'll be more than willing to incorporate the feedback into the vpatch. Otherwise, it'll stay as is, and I hope that one day it'll make it into FFA vtree.

The next item scheduled for implementation was ripping out Linux kernel RNG and replacing it with a driver that could be directly fed with random data provided from userspace (i.e. from FG). To provide a more specific work plan:

1. There is a blog post in progress, of the "let's read together" sort, about the current Linux RNG code, and what expectations of other parts of kernel and userspace it should satisfy. This work should be finished by the end of next week (18.08.2019)¹.
2. I'll do a few experiments with the source code, using a prototype implementation of the driver. The main question is whether the system would be able to boot to userspace without any random numbers available². This should take 2-3 week to finish (~08.09.2019).
3. The clean implementation of the modified RNG driver as outlined above. The time for doing this coincides with my certain plans in meatworld, so I'll have to dedicate a month of work for it (until middle of October).

One of the decisions that I'll have to make along the way is to pick a version for kernel genesis: very quick test shows that vdiff indeed can handle a project of Linux's size, however there are some binary files there that would be lost (some images and pdf documentation). The bigger issue is that vpatch chokes on dotfiles, which are present in the Linux tree as well:

$ cat ../test.vdiff
diff -uNr a/.test b/.test
--- a/.test false
+++ b/.test 237333992aa0d343b4f59b2c2a31cd8c3f34762be261b4bb223e4de887d46e7be33538d9ad052a1fe04f0d2ba954e6e14191d1d31a8b99af0640895de984bd89
@@ -0,0 +1 @@
+test
$ vpatch < ../test.vdiff  
creating .test

raised ADA.IO_EXCEPTIONS.USE_ERROR : new name ".test" designates a file that already exists
$ ls -a1
./
../
.test/
vpatch-1a7d54090ee183e939ad4ba8ec610bbbfd2d46458e3b8800c16a10bdbfa347e8bfc41a036e22987dc7d63f57eb9f8f61eff3f7920b71c0ef2e42adaeca0085a9

That is, in case of dotfile, a directory is created instead for some reason. I'll have to produce a fix for this as well³... Anyhow, so far I plan to genesis a kernel currently used in Cuntoo, unless there are objections to it: unless something like kernel 2.4 is used, all the differences between 2.6.X-3.Y-4.Z kernels are in architecture support; as far as x86 is concerned, different sets of bugs&fixes to drivers would be the whole difference.

I'd like to hear your comments on these things.

1. Reflecting on the proper time accounting practice, one of the mistakes that I have done several times already is not giving myself proper amount of time for write-up. Yes, work can take a week; but the write-up can take a week as well. [↩]
2. There is an interface for "reading/generating" random values for in-kernel consumption, and its interaction with the boot process is not clear to me yet. Just reading the source to fish out this information seems to involve too many components, so I would like to take an experimental approach here. [↩]
3. While creating the reproducer vpatch shown above, I discovered that vpatch does not handle empty vpatches too. Funny, how these things accumulate. (For this, I already have a fix). [↩]