[libcamera-devel] [PATCH] libcamera: ipa: allow trusting modules by checksum

[Arnout Engelen]

Hi all,

On Sun, Jan 21, 2024, at 19:54, Laurent Pinchart wrote:
> On Sun, Jan 21, 2024 at 04:32:06PM +0000, Kieran Bingham via libcamera-devel wrote:
> > Quoting Elias Naur via libcamera-devel (2024-01-21 14:09:52)
> > > Hi Arnout,
> > > 
> > > > The motivation behind adding this mechanism is that this allows rebuilding the
> > > > library and getting a bit-by-bit identical result, without having to share the
> > > > keys with which to sign the trusted modules. This is known as 'Reproducible
> > > > Builds', and you can read more about its advantages on
> > > > https://reproducible-builds.org/. With this feature, packagers that care about
> > > > reproducible builds can disable the module signing, and enjoy equivalent
> > > > security and performance while also allowing independent rebuilds.
> > > 
> > > Thanks for working on reproducible builds. I locally hack libcamera
> > > to achieve bit-for-bit reproducible builds, and look forward to no longer needing
> > > that hack.
> > 
> > I agree, finding a solution to handle reproducible builds is a good
> > goal.

Thanks for the encouragement!

> > > I think the feature would even more useful if it were always enabled. In particular,
> > > I propose to:
> > > 
> > > - Always enable checksums.
> > > - Embed the known checksums into the binary, not in a separate configuration file.
> > 
> > I think this is a fairly important requirement to be able to upstream a
> > reproducilble builds solution. The checksums should be stored within the
> > libcamera binary so the configuration file can not be amended after the
> > fact, which would otherwise defeat the purpose. 
> > 
> > But this makes things much more difficult I believe...
> > 
> > The tricky parts here will be handling how to verify the checksum of the
> > modules while distributions do actions such as stripping symbols. There
> > are legitimate modifications that can be made to the module as part of
> > the installation process which would then break the checksum
> > verifications.

Indeed: embedding the checksums in the binary was my initial approach, but it's tricky given the legitimate use cases for modifying the objects in the install phase.

> Checksums in a configuration file is a no-go I'm afraid, as it means
> anyone could ship a closed-source IPA module and instruct users to add
> an entry to the configuration file, circumventing IPA module isolation.

It depends on your threat model / risk appetite, of course - it's hard to protect against users that are happy to explicitly trust such a third-party module. Going to extremes, someone could even try to convince such users to load a version of libcamera that trusts their module, or other terrible hacks. I guess we don't want to make it too easy, though.

I'd be happy to provide a version of this patch with the 'LIBCAMERA_IPA_TRUSTED_MODULE_CHECKSUMS_FILE' environment variable support removed, and a meson option to enable/disable trusting checksums - default value up to you. That may increase the barrier and give distributions a chance to make their own trade-off?

(I also like Elias' idea of statically linking the in-tree modules, but I don't think I'm comfortable enough with the codebase to take that on)

> > > - Don't sign IPAs that have known checksums (thus achieving bit-for-bit reproducibility).
> > >   - In your patch, I believe this is equivalent to "ipa_sign_modules" always being false.
> > 
> > Would there be a mix of signed+checksummed modules in a given
> > distribution?

I don't see an obvious use case for having both, but I don't see a reason to restrict it either.


Kind regards,

Arnout
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20240122/bcecc9c1/attachment.htm>