[Trustable-distros] Experimentation Towards a Trustable Minimal Linux Distribution

Ben Brewer ben.brewer at codethink.co.uk
Fri Jul 20 11:32:38 BST 2018


On 20/07/18 10:54, Paul Sherwood wrote:
> Hi Ben
> On 2018-07-19 14:20, Ben Brewer wrote:
>> So over the past couple of weeks we've been attempting to get a good
>> minimal distro using definitions and both ybd and bst, here are our
>> findings so far.
>>
>> We tried building the "morphs" branch of definitions using YBD, and 
>> found:
>> 1. The "morphs" branch is a bit out of date.
>>      - Dependencies are not tracked properly in morphs because of 
>> leakage.
>
> What do you mean precisely by 'leakage', please?
Say package A depends on package B.
And package C, depends on package A.
Package C will have Package B staged, despite not having it as a direct 
dependency, even though it may not require it.
This leads to a situation where packages have dependencies that are 
indirectly met, and not documented.

>
>> 2. YBD was in some cases crashing with python errors that made little 
>> sense.
>
> Eek.
>
>> 3. Because morph files don't differentiate between runtime and
>> build-time dependencies, it's very hard to build a minimal system:
>>      a) Though the runtime should be 4 packages, there are a lot of
>> build dependencies.
>
> Yes understood.
>
>>          - Our current system is 81 elements total.
>>      b) Many overlaps are caused by dependency leakage.
>> 4. YBD seemed a little faster than BuildStream
>> 5. YBD needs to be run as sudo
>
> Fraid so.
>
>> We found that by switching to BST, we gained a number of advantages.
>> 1. The runtime/build split allows for proper dependency tracking.
>> 2. Much easier to debug using BST log and shell commands.
>> 3. It's a little easier to track what's going on.
>>
>> One feature we'd think is very important for BST is an easy way of
>> tracking the number of runtime dependencies deployed in the final
>> system, although I guess this could be scripted (this has been
>> reported).
>
> Is there an issue raised for that?
Yep: https://gitlab.com/BuildStream/buildstream/issues/406
Also discussed here: 
https://gitlab.com/BuildStream/buildstream/issues/416 
<https://gitlab.com/BuildStream/buildstream/issues/406>

But as it turns out the functionality somewhat exists via:
bst show <elements> --deps run

Also, if run against a deployed image then it doesn't show the deps, so 
you have to have some insight.

So I guess this is a documentation issue, probably just that there's no 
documentation for building a distro where the command would be most useful.
>> In resurrecting Baserock definitions, we discovered the following
>> (non-exhaustive) list of issues:
>> 1. Linux header version didn't match the kernel version.
>>      - No automated checking is performed, but should be in many
>> cases, especially for bootstrapped components.
>
> That sounds like it would be an easy and useful thing to have a test 
> for in any 'trustable' implementation?
Yes, it needs some thinking about. We need to remove as much duplication 
or scope for error as is practical.
>
>> 2. Most packages have invisible dependencies, for two reasons:
>>      a) Baserock used the "Strata" concept, which don't track
>> dependencies accurately.
>
> Yes - that was/is a simplification
Yeah, I've always thought it a bad one, and mentioned it before. 
Hopefully we can fix it now :)
>
>>      b) Most elements incorrectly list their build depends as runtime
>> dependencies which causes leakage.
>
> Ack.
>
>> 3. Many packages are simply downloaded tarballs which have no
>> provenance and are not trustable (in our opinion).
>
> Noted.
>
>> 4. There are many issues with bootstrapping:
>>      a) Many packages have circular dependencies and are not correctly
>> bootstrapped.
>
> I'm surprised by that, actually. Certainly at the time it seemed that 
> quite a lot of effort was expended on 'bootstrapping'
Only toolchain items are bootstrapped, which is basically gcc, binutils 
and glibc (and a few others).
Some pretty major stuff is not bootstrapped though: autoconf, automake, 
libtool, flex, bison,  etc.
>
>>          - For example coreutils depends upon itself, and baserock
>> compiles a random "join.c" from openbsd to resolve that dependency :/
>
> Hmmm. I'm almost tempted to look at git blame for that. But probably 
> it would be more constructive just to say, let's start afresh and do 
> it 'properly'.
It's not the worst compromise, but I probably wouldn't have made it.
>
>>      b) The bootstrapping is very fragile, updates to many packages
>> require the entire universe to be bootstrapped:
>>          - GLIBC for example would require flex, bison and their
>> dependencies to be bootstrapped if we want to update it.
>>      c) In many cases bootstrapping is avoided by including tar files,
>> this is not a trustable way to build from source (in our opinion).
>>      d) bootstrapping is very complicated and causes a lot of
>> duplication, some automation of this would be highly beneficial.
>> 5. There are so many hacks, scripts, or modified branches used for
>> building various components that it's actually very difficult to
>> update components at all. Linux is one of the few elements that can
>> easily be replaced.
>>
>> We believe it is possible to fix the issues above, however these are
>> not trivial issues to resolve.
>>
>> With regards to the discussion where we set a goal of a toolchain with
>> 7 packages, and a runtime of around 3, we believe that to be
>> impossible if we perform proper bootstrapping. The numbers at the
>> minute seem to indicate that we could build a minimal system with 4
>> packages:
>>      syslinux (bootloader), linux (kernel), toybox (environment), 
>> musl (libc)
>> However, the toolchain will likely require order of 50 packages (more
>> elements due to grouping and staging).
>
> Right. Even though it's non-trivial, I'm currently leaning towards the 
> 'let's do it properly'. But let's consider this more deeply over the 
> next few days.
Yeah, I don't think we have any option but to 'do it properly', we just 
have to nail down what that is :)
>> Our current work can be viewed here:
>> https://gitlab.com/trustable/distros/minimal-distro
>
> Thanks!
>
> Paul
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/trustable-distros/attachments/20180720/84976a1e/attachment-0001.html>


More information about the Trustable-distros mailing list