Direkt zum Hauptbereich

Securing recipe against manipulation by other layer in YOCTO

In my last post I described a way how to ensure a safe and know configuration for KConfig-based system.
But there is a lot more that could be altered when you include additional layer into your workspace. Just think of

  • configure options
  • build instructions
  • additional patches being applied
  • license changes (a very bad one)
  • files remove which should have been there
  • a.s.o.
I though about this for a longer time... after a very deep dive into the way bitbake is handling the parsing of any file (bb, bbappend, inc, conf) I created a small helper bbclass which you can find here.

This class can monitor changes done by bbappend file (no matter where they are actually located in your workspace) and diff them to the plain recipe.

You can now define a set of variables which you don't want to be changed at all (like. SRC_URI, or LICENSE).

The helper class does then the magic for you and diffs them against each other.
If a variable (and all there machine/arch-specific variants) is on the monitoring list and a bbappend alters this - you will get a reasonable warning, what and to which value the change happened.

What about files...?


The bitbake-construct does also offer the possibility to overload files

Just think of the following directory structure
  • recipes-foo
    • foo
      • files
        • foo.file
      • foo_1.2.3.bb
  • recipes-bar
    • foo
      • files
        • foo.file
      • foo_%.bbappend
now take a guess which "foo.file" will make into the build?
The answer: it depends!

If the file "foo_%.bbappend" contains a line like this
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
the file from the bbappend-subdir will win. If not the it's mostly likely that the "original" file will make it.

This behavior is a gift and a curse that the same time.

The class I wrote, does help you to make it into a gift only.
It offers the possibility to check if a file is defined more than once among the bb-file and all bbappends.
This is also configurable, so you can just set the filter to the files you really don't want to altered by anyone (e.g. defconfig is a typical example).


I wrote the layer-safety.bbclass as part of my collection meta-buildtuils of useful helper functions.

I would be happy to get your input here in the comments or over on GitHub.
Labels:

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Speedup python on embedded systems

Have you ever considered to use python as a scripting language in an embedded system? I've been using this on recent projects although it wasn't my first choice. If I had to choose a scripting language to be used in embedded I always had a strong preference for shell/bash or lua, because they are either builtin or designed to have a significant lower footprint compared to others. Nevertheless the choice was python3 (was out of my hands to decide). When putting together the first builds using YOCTO I realized that there are two sides to python. the starting phase, where the app is initializing the execution phase, where the app just processes new data In the 2nd phase python3 has good tradeoffs between maintainability of code vs. execution speed, so there is nothing to moan about. Startup is the worst But the 1st phase where the python3-interpreter is starting is really bad. So I did some research where is might be coming from. Just to give a comparison of ...
Kommentar veröffentlichen
Mehr anzeigen

Using bbclass based on conditions

When you are working with YOCTO build system, you might be aware of the construct .bbclass. For those who are not: these are code snippets which will be injected into the recipe itself. Mostly they add new tasks or provide some generalization for things you often. A good example might be pypi.bbclass. In your recipe you write usually something likes this SRC_URI = "https://www.foo.org/foo.tar.gz" When it comes to python packages a way more elegant way is to use pypi.org . And here does the pypi.bbclass provide some magic - you recipe will just look like this inherit pypi   PYPI_PACKAGE = "foo" the bbclass pypi will automatically translate the variable name PYPI_PACKAGE into a valid URL to fetch the package. Also it will set some internal variables such as HOMEPAGE or S to the correct settings. You see life can be convenient when you know how to do it. If you want to apply a bbclass you can either insert inherit foo.bbclass into each recipe or you...
Kommentar veröffentlichen
Mehr anzeigen

Making KConfig safe to use with YOCTO

As you may know KConfig is a well-known system for configuring software modules, as used by busybox , linux kernel , u-boot and many more. If you are unfamiliar you might want to read this nice tutorial . So as KConfig is well established it is used at different locations throughout YOCTO. Basically YOCTO is doing it the following way. You have a base configuration file called "defconfig". This is placed somewhere in the recipe-tree. It describes the absolute minimum of configuration needed. Depending on the feature you want to add, there are *.cfg-file around the recipe-tree. The configuration is done with all the *.cfg-files being merged into the defconfig. This is passed to "make oldconfig" to sanity check and put all the not defined symbols into the configuration. And voila you have a fresh valid configuration to build your software. It's pretty obvious that this is one stage where things can go very wrong...! Mostly the basis (KConfig) is chan...
Kommentar veröffentlichen
Mehr anzeigen