All right, so, please settle down, while more people are tricky to lean, we have
max already starting with Kerala's bomb, hey, I hope, I think it's so long, yeah, I
am as a, hey, I'm max, I work at a IT consistency in Munich, Germany, doing some
consulting stuff, and one part was working on creating an S-bomb for the Linux
cone, and with the goal to have that tooling part of the cone sauce so that it can
always be generated automatically. The tool, the development part of the tool is currently
in this repository, and it's to generate an S-bomb, you just take the sauce fee, the
object fees or the build output, and it will generate a S-bomb for you, and the vision
is what's in its merge, and once it's contributed, you just call make S-bomb, and you
have the S-bomb of the current cone, but let me explain how we get the metadata or the build
graph for that S-bomb. The Kerala build, so that's a specific thing within the
Kerala build, is that it generates .zmd files, this Java, this .zmd files here, they contain
metadata about the build and about what happened, and we pass them, and an example for
that is, so these are two examples, they are either just contain the make come up that
was used for that specific target, or they even contain additional source and dependency
information. If we look into that, it's, that's an example, it's the VM Linux file, and
the corresponding .zmd file is shown here, and you see it calls Aldi, it has a lot of
.ofs, as inputs, and it builds as an output, the VM Linux file, and for that we see, we
can start constructing the graph of dependencies or file level dependencies within the Linux
file. Another example is, here, the Kerala info.0, and that's one of the examples where
the dependencies are already mostly extracted by the K-build build system, so it says,
that's my source file, it's the .s file, and that are my dependencies, some .h files, so
it's easier to extract the graph from the build, and additionally to these two cases, where
we have the metadata, oh, I start slowing down, I see I was a little bit stressed in the beginning,
so I'm not getting relaxed, right, additional to the .zmd files that we need, or that we have,
where the data is already present, there are two cases where we need to fill some gaps,
there are .appercase s files that contain .inkbin, I think that's include binary statements,
these we need to pass them by hand, and add them to the build graph that we are building,
and these files that are included, then again, have .zmd files and we can follow the graph
even further, and there are some other cases where we currently still have to hard count the
dependencies, so that there are some gaps that we still need to fill manually, but we hope that
we can improve the cable script, and other tools to fill the gaps and get rid of this annoying
ugly hard coding at some places, but I always link the issues in this light, if you download
them online afterwards, so that's basically the first part of the presentation already done,
I think I am too fast, but yeah, more time for questions, so we build a graph from the
curl build by looking through the .zmd files, these two cases that I have shown, we have the
include binary statements and some hard coding and that results in this build graph, and
we have built tooling just to understand what's happening, but can visualize that, if you
run the scripts, it's JavaScript, Sumable Visualization of the kernel build, and you can find out
how does it all relate, and we also worked on validating if it is complete, since we might miss some
stuff, so we did, we compared our data against an output of an s-traced kernel build, and saw that we
have a 99.6% overlap, so it's still not 100%, so there are still some gaps, but the s-traced build
also overreport some parts, so we are still in a moving towards 100%. And the second thing that we did
is we just removed all files that are not listed and the kernel still built, so that's also a good sign.
Yeah, that was part one, that's the data and how we get that, how we build the graph, and
part two is what's to be generated from that data. We are generating spdx files as s-boms,
I think we have heard a lot about spdx today already, and matching what we have heard today,
we are generating three different s-boms, the output s-bom, I think that's not one of the listed
names of types, but it's this single s-bom that describes the package that contains the
commetadata and contains just the high-level information, it is very small and can be shared easily,
it has some of the essential hashes, it has some of the essential metadata, and it's just the
small thing that can be shared. We have the source s-bom that contains the final level information,
and we have the build s-bom that represents the whole graph that links the sources to the final
output, and yeah there's an edge case, the to distinguish between what the source, what is
the immediate file way we need to have an out of three builds so that these two parts are
than two different directories, that's how we distinguish them. So yeah and just to have also
as light with way to small font, that's how internal structures it's a lot, but I have split it up
into all the individual pieces, and that's the remainder of my presentation just to explain how
that all looks in detail. So the source s-bom that contains the final information it's basically
filled with the hashes of the individual files, some of the statically extractable information like
SPDX license identifiers that are in the file, and we do some basic horrific to guess what type of
file it is if it is a source file if it is a asset, all these things are tried to guess, and that's
a simple entry of one of these files, just what I've said, machine-reelable s-tracing LD,
and the source s-bom is basically a huge list of these, listing exactly the used files,
and they are linked to the licenses with the has declared license relationship since this is part
of the graph structure within SPDX. And on the other hand, on the other side of the spectrum,
there's this output s-bom that contains the software package for the Linux kernel for all the
modules that were contained in the build, and these packages are linked to the files that
represent the packages with the has distribution artifact, so that's the first bridge from
the metadata to files in the file system, and these distribution artifacts are also the tip of the
build tree in the end, and that's the high level build element, since we also
generate the build structure, that's the top of the build tree, it describes the, so it's basically
the entry point of the top level build, but to get a deeper, there's the build s-bom in between
that describes all the real details or the what command was used, what which files depend on which
file, so this is then what this encodes the whole tree, and this is in the middle file,
and all these small builds that are listed or the build objects that are just encoding a single
command that was run during the build, they are linked with the ancestor of relationship to the high level
build, and that's an example of that data, it's a build step, it has a comment that describes
what was the command that was used, and it has two relationships which link the inputs on the
one hand, and which link to the outputs on the other hand, so in the end it's build element that
has these two relationships, and that links files in the file system together, and that builds the graph,
so that's the file structure, and that contained a lot of details that I just went over pretty fast,
maybe they are questions in the end, but yeah what's next with that project, then the big goal
currently is to get it into the kernel source to get it into a sub directory in the kernel sources,
and make it part of that, there's currently a contribution in process, and if that is
merged in the end, you can just after a successful kernel build called make SPX, no,
make S bomb that, that's a type of it should be make S bomb is the command in the end,
I can, I don't fix that right now, but that's the command in the end,
and that is also described in the email conversation that is currently happening, that's the
current contribution that is in progress where we are discussing with maintainers,
how to, how to adopt what to fix and how to get it aligned with the expectations,
and we hope that we soon get green light and that it gets merged, not sure at which
release it will arrive in the end, and further next steps, we are interested in feedback,
if you want to look at the output files, the CI is generating BAM for 203 example builds,
that are uploaded as assets to the CI, so you can look at examples, you can investigate examples,
we are thinking about broadening the support for architectures, since we don't have for all
architecture and analyze what are the gaps, what do we need to get to 100%,
so there's more work to do, and we want to understand how this could integrate with other
buildings, for example, if a Yachter builds something containing the kernel and itself builds
aspects, how to bridge the gap, how to interlink them, and how to have them pointing at each other,
I see a thumb up, yay, and that's it, on the right, that's the QR code to the repository,
and on the left that are my coordinates, you can reach out to me, and now questions,
so BSI is asking for 512 hashes, is it possible to potentially parameterize it so people can
generate the 512 hashes automatically? We are using, so, we're using 256, yeah,
for sure it's possible, we are using the native Python support for generating hashes,
the whole library is built without any external dependencies, that was a requirement,
that's why we use no other open source, SPDX2, but yeah, it's I think the support is there,
if we just need to do a minus switch, or we can add parameters, yeah?
So the question was, what do I think about incompatibility, compatibility
about around the ecosystem, so for example, if we go to Yachter and the Slainx kernel build,
or what ecosystems do you want to compare, from SPDX to CDX, for example, the conversion between
S-POM ecosystems, I think it's a hard problem, I think we, for example, the build tree that is
encoded here, that has an instance of relationship that links the high level built in the
low level builds, which is a concept, I don't know whether it is, there's something that it can
compare to, it's a dependency in Cycle and DX, but at the same time, tool that's what's
understand, dependencies, okay, Anthony, your name was Anthony, right? Anthony said that it would
be a dependency in CDX and you would need to add a comment or metadata to to encode that it's
basically a dependency of builds and other dependency of dependencies, so it's, um, there's a lot to do, yeah?
Yes, the relics kernel has put the SPDX ideas in the source code, yeah, and potentially to this
relicating syntax, a GBL to the zero instead of the zero only, or only, or like, so I try to
convince them to correct that, because we don't care. But even on the SPDX, the question was that
the Linux kernel still uses the GPL 2.0 as, uh, identifies, which are, deprecate, it's deprecated
the right route, but they are still correct, valid. Yeah, but the kernel people want to be short.
Yeah, um, I can repeat the answer, the FSF requires the, there's only the curl wants to keep it short,
but I'm still thinking that GPL 2.0 is still not valid, I identify, but the, deprecate is still
valid as PDX, yeah, any other questions, uh, in the back there? So, the architecture differences,
what are the main features for making this work for, say, how will PC you work this time?
Um, it's this completeness analysis, um, what are the issues with getting it to work for power, PC,
and risk five? The issues are that, um, some of the tools behave differently, um, we have,
I mentioned that we are passing the, uh, the commands, so this example here, so there's a command
string that are, that we are passing, if they are different tools and what we need to write different
passes that support these tools, that is one, um, problem, and the second problem is that,
um, there might be more things to be hard-coded, there might be more edge cases to be supported,
so they, all the completeness analysis needs to be done, and it's, it works, but there's a less
guarantee that it's complete, and it might run into problems, if commands cannot be passed.
They include binary things, and your assembly is different in the other assembly.
So, thank you very much, Max.
Thank you for giving us your work going.