bug#72828: Grafting breaks libcamera signatures

[Jacopo Mondi <jacopo.mondi@ideasonboard.com>]

[-- Attachment #1: Type: text/plain, Size: 4095 bytes --]

Hi Andrew, Ludovic,

On Wed, Sep 04, 2024 at 09:42:17PM GMT, Andrew Tropin wrote:
> On 2024-09-04 18:42, Ludovic Courtès wrote:
>
> > Hi Jacopo,
> >
> > Jacopo Mondi <jacopo.mondi@ideasonboard.com> skribis:
> >
> >> Not exactly. In libcamera, apart from creating a library to ease all
> >> the camera stack plumbing, we're creating an ecosystem of open-source
> >> 3A algorithms (what we call the IPA modules).
> >>
> >> Camera vendors and ODMs which invested in products with specific
> >> camera features, consider 3A algorithms and their tuning their secret
> >> sauce and are usually not willing to consider releasing them as open
> >> source with, fortunately, notable exceptions such as RaspberryPi
> >>
> >> Please note that all the platforms libcamera supports have an
> >> open-source 3A algorithm module available part of the main code base,
> >> and we consider open source 3A modules our 'first class citizens' and
> >> we're willing to develop and maintain them in libcamera mainline
> >> branch as free software, but at this point we have to provide a way for
> >> third-parties to load binary modules if they want to.
> >>
> >> The alternative is to have them continue developing camera stacks
> >> fully behind closed doors as it has been done so far.
> >
> > OK, I see, thanks for explaining the context.
> >
> >> As said, modules not built against the libcamera sources will not be
> >> signed, as they are distributed by other means by a vendor in binary
> >> form. To establish if a module has been built with the libcamera
> >> sources or not, we sign it during the build with a volatile key and
> >> validate the signature at run-time, when the IPA module is loaded.
> >>
> >> IPA modules for which the signature is not valid (either because they
> >> are distributed as binaries or, as in this case, because the build
> >> system strips symbols before installing the objects) are loaded in an
> >> isolated process and instead of being operated with direct function
> >> calls, we have implemented an IPC mechanism to communicate with them.
> >> This path is way less tested by our regular users and in our daily
> >> work on libcamera. Vendors that are running their binaries as isolated
> >> might have fixed issues here and there but maybe they have not
> >> reported the issue and the associated fix upstream (we have no control
> >> over this).
> >>
> >> For this reason I don't suggest running modules as isolated, even more
> >> if you have no reasons to do so. If all it takes is re-signing IPA modules
> >> after stripping them as Andrew did I would really consider doing that.
> >
> > Yeah, got it.  The other option, with the understanding that IPA modules
> > are all going to be free software here, would be to dismiss both the
> > authentication and the isolation mechanism, possibly with a custom
> > patch.  It seems like the change wouldn’t be too intrusive and it would
> > solve the problem for “grafts” as well (grafts modify files in a
> > non-functional way).
>
> On 2024-09-02 10:45, Andrew Tropin via Bug reports for GNU Guix wrote:
> > Anyway, I think the current most reasonable solution is to remove
> > signing step at all, because the signaturs will be invalidated by
> > grafting anyway and make it work somehow (either by loading in
> > isolation if it's possible or by loading unsigned libraries without
> > signature check directly).
>
> Everything indicates that we need to disable module authentication.
>
> Jacopo, I think I'll patch IPAManager::isSignatureValid to always return
> true.
>
> https://git.libcamera.org/libcamera/libcamera.git/tree/src/libcamera/ipa_manager.cpp#n285
>
> Like that:
>


>
> Everyone is ok with it?

At this point is a distro decision, either if you prefer to carry an
out-of-tree patch in your tree or tweak the build system.

Be aware that, sooner or later, the signature mechanism will be reworked and
your custom patch might not apply anymore.

Up to you :)

>
> --
> Best regards,
> Andrew Tropin




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]