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

[Laurent Pinchart]

On Mon, Jan 22, 2024 at 09:50:02AM +0100, Arnout Engelen wrote:
> 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.

There's also a chicken-and-egg issue I believe, as the in-tree IPA
modules have to link against the libcamera binary, and checksums can
only be computed after the IPA modules have been linked.

> > 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.

That's the idea, yes. libcamera being open-source, users can ultimately
disable any protection method we put in place. We don't want to make it
easy to circumvent this, not so much towards the users, but towards the
closed-source IPA module providers.

> 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'm afraid I'm still not comfortable with that. If we want to use
checksums, I think we need to embed them in the libcamera binary.

> (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)

I've been sleeping over this, and it's an interesting idea to explore I
think. There will be technical issues to solve though, as we want to
make it possible for users to select between different IPA modules for
the same platform.

> > > > - 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.

-- 
Regards,

Laurent Pinchart