[oe] [meta-ota][PATCH] meta-ota: add support for binary-delta images in a new layer

[Bartosz Golaszewski]

pon., 2 mar 2020 o 19:25 Khem Raj <raj.khem at gmail.com> napisał(a):
>
> >
> > Khem, Armin: any thoughts?
>
> there are many ota layers on OE, most of them are self-contained, so a
> question arises, how is this different, somethings here say it could be
> a base layer for all OTAs, which actually seems quite valuable, but it
> has to be such that the existing OTA layers start using pieces from this

No, it's actually the other way around. The existing OTA layers are
focused on supporting specific tools and they usually provide full
support for some reference platforms. However in every custom project
I worked on we needed to extend those layers and those extensions
became quite repetitive, hence the idea for a layer that gathers
common elements but that is independent from project-specific layers.

If anything the goal is to use this *in conjunction* with specialized
OTA layers.

> layer, Other part seems to be that its yet another OTA using binary
> delta update techniques, so in such a case, it should be thought of as
> another OTA and perhaps maintained independendently, if there are
> features which are common across all OTAs we can host them in core or
> meta-oe,
>

No, this is not an OTA on its own and the generation of binary delta
patches is just one of the features.

Let me give you more context on why I started to do this. We've had a
downstream layer for a client's project compatible with thud with a
complete verified boot chain of trust including dm-verity protected
rootfs mounted by an initramfs stored in signed fitImage + OTA
support. Generating this image required us to alter a couple
inter-task dependencies (fitImage needs to wait for initramfs, but
initramfs needs the dm-verity meta-data which needs the rootfs
partition, and then we need to sign the fitImage etc. etc.).

Then some time during warrior development commit 67628ea66b7d
("uboot-sign.bbclass: fix signature and deployment") was merged in
OE-core which caused us a lot of trouble with our dependencies when
trying to update the layer. In order to not make the same mistake
twice - we thought it's best to upstream our development too for
others to use and to be able to object when someone breaks it for us
(I'm mostly a kernel developer and this is how it works in linux, I'm
not sure if it's the same for yocto).

BTW I'm also preparing a series of patches for meta-security with
dm-verity images as part of this effort.

If this is not something that should be part of meta-openembedded - is
there any way to have it hosted at https://git.yoctoproject.org/cgit/
as an official yocto layer? I'm sorry if this is a dumb question, I
don't know exactly what the policy is for that.

Best regards,
Bartosz