GNU bug report logs - #72828
Grafting breaks libcamera signatures

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72828 in the body.
You can then email your comments to 72828 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrew Tropin <andrew <at> trop.in>
To: bug-guix <at> gnu.org
Subject: Grafting breaks libraries signatures
Date: Tue, 27 Aug 2024 14:46:40 +0400

[Message part 1 (text/plain, inline)]

TLDR: libcamera checks the signatures of its own libraries, when loading
them, grafts are enabled by default in Guix, grafted libraries fails to
pass the check.


The full story:

For the last a few days I was updating and fixing libcamera package.

The last problem I faced with it is invalid signatures:

[0:44:16.200646504] [17247] DEBUG IPAManager ipa_manager.cpp:316 IPA module /gnu/store/pfh7adzzy8akkqsjj4wlnmvmbzmrfbvk-libcamera-0.3.1/lib/libcamera/ipa_soft_simple.so signature is not valid

The full log:
https://paste.sr.ht/~abcdw/09e6d4aa66c8fb70a1e8e7e91bfef4cae5aa4e24#cam2.log

I thought it was because of grafts and tried to build it with
--no-grafts, it didn't help.  After that I realized that the signature
created during install phase and before strip phases.  I added a phase
after 'shrink-runpath and it helped:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=4a19fe41c3

qcam now shows the image, after that I removed --no-grafts flag and
built the package again and the problem came back (now because of
grafts).

The issue with related discussion in libcamera backtracker:
https://bugs.libcamera.org/show_bug.cgi?id=231


How we can solve or workaround this problem?

-- 
Best regards,
Andrew Tropin

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 72828 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Andrew Tropin <andrew <at> trop.in>
Cc: 72828 <at> debbugs.gnu.org
Subject: libcamera module signatures
Date: Sat, 31 Aug 2024 21:36:49 +0200

Hi Andrew,

Andrew Tropin <andrew <at> trop.in> skribis:

> For the last a few days I was updating and fixing libcamera package.
>
> The last problem I faced with it is invalid signatures:
>
> [0:44:16.200646504] [17247] DEBUG IPAManager ipa_manager.cpp:316 IPA module /gnu/store/pfh7adzzy8akkqsjj4wlnmvmbzmrfbvk-libcamera-0.3.1/lib/libcamera/ipa_soft_simple.so signature is not valid

I was curious about those signatures so I browsed ‘ipa_module.cpp’ and
‘ipa_manager.cpp’.  I wondered: what is that supposed to protect against
in the first place?  Bogus LD_LIBRARY_PATH that leads users to load
third-party code instead of the intended module?

Apparently those loadable modules can be isolated in separate processes
when they lack a valid signature, or when LIBCAMERA_IPA_FORCE_ISOLATION
is set.  ‘ipa_manager.cpp’ sheds some light on the rationale for so much
sophistication:

 * Module isolation is based on the module licence. Open-source modules are
 * loaded without isolation, while closed-source module are forcefully isolated.
 * The isolation mechanism ensures that no code from a closed-source module is
 * ever run in the libcamera process.

This probably makes sense in the context that the copyright owner,
Google, envisioned: presumably Android programs loading random
proprietary modules coming from the app store.  But I wonder what the
point is in the context of a free GNU/Linux distro.

In Meson there’s an ‘ipa_sign_module’ boolean variable and
‘src/meson.build’ says this:

--8<---------------cut here---------------start------------->8---
if openssl.found()
    ipa_priv_key = custom_target('ipa-priv-key',
                                 output : ['ipa-priv-key.pem'],
                                 command : [gen_ipa_priv_key, '@OUTPUT@'])
    config_h.set('HAVE_IPA_PUBKEY', 1)
    ipa_sign_module = true
else
    warning('openssl not found, all IPA modules will be isolated')
    ipa_sign_module = false
endif
--8<---------------cut here---------------end--------------->8---

Perhaps we should try removing ‘openssl’ from the inputs and thus have
all the modules isolated?

Ludo’.

Message #13 received at 72828 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Tropin <andrew <at> trop.in>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 72828 <at> debbugs.gnu.org
Subject: Re: libcamera module signatures
Date: Mon, 02 Sep 2024 10:45:52 +0400

[Message part 1 (text/plain, inline)]

On 2024-08-31 21:36, Ludovic Courtès wrote:

> Hi Andrew,
>
> Andrew Tropin <andrew <at> trop.in> skribis:
>
>> For the last a few days I was updating and fixing libcamera package.
>>
>> The last problem I faced with it is invalid signatures:
>>
>> [0:44:16.200646504] [17247] DEBUG IPAManager ipa_manager.cpp:316 IPA module /gnu/store/pfh7adzzy8akkqsjj4wlnmvmbzmrfbvk-libcamera-0.3.1/lib/libcamera/ipa_soft_simple.so signature is not valid
>
> I was curious about those signatures so I browsed ‘ipa_module.cpp’ and
> ‘ipa_manager.cpp’.  I wondered: what is that supposed to protect against
> in the first place?  Bogus LD_LIBRARY_PATH that leads users to load
> third-party code instead of the intended module?
>
> Apparently those loadable modules can be isolated in separate processes
> when they lack a valid signature, or when LIBCAMERA_IPA_FORCE_ISOLATION
> is set.  ‘ipa_manager.cpp’ sheds some light on the rationale for so much
> sophistication:
>
>  * Module isolation is based on the module licence. Open-source modules are
>  * loaded without isolation, while closed-source module are forcefully isolated.
>  * The isolation mechanism ensures that no code from a closed-source module is
>  * ever run in the libcamera process.
>
> This probably makes sense in the context that the copyright owner,
> Google, envisioned: presumably Android programs loading random
> proprietary modules coming from the app store.  But I wonder what the
> point is in the context of a free GNU/Linux distro.
>
> In Meson there’s an ‘ipa_sign_module’ boolean variable and
> ‘src/meson.build’ says this:
>
> --8<---------------cut here---------------start------------->8---
> if openssl.found()
>     ipa_priv_key = custom_target('ipa-priv-key',
>                                  output : ['ipa-priv-key.pem'],
>                                  command : [gen_ipa_priv_key, '@OUTPUT@'])
>     config_h.set('HAVE_IPA_PUBKEY', 1)
>     ipa_sign_module = true
> else
>     warning('openssl not found, all IPA modules will be isolated')
>     ipa_sign_module = false
> endif
> --8<---------------cut here---------------end--------------->8---
>
> Perhaps we should try removing ‘openssl’ from the inputs and thus have
> all the modules isolated?
>
> Ludo’.

It seems by default libcamera fallbacks to loading the module with
invalid signature in a separate process, however in my case it
segfaulted and killed pipewire in addition to that.  Not sure that all
the modules can be properly loaded in isolation, will clarify it with
libcamera devs.

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

WDYT?

-- 
Best regards,
Andrew Tropin

[signature.asc (application/pgp-signature, inline)]

Message #16 received at 72828 <at> debbugs.gnu.org (full text, mbox):

From: Jacopo Mondi <jacopo.mondi <at> ideasonboard.com>
To: 72828 <at> debbugs.gnu.org
Subject: Grafting breaks libcamera signatures
Date: Mon, 2 Sep 2024 10:37:58 +0200

Hi, I hope this mail reaches the issue tracker.

I'm one of the libcamera developer, and while I cant share any useful
opinions on the guix build issue, I would like to clarify some points
from the discussion above in order to help better understand the
context on why we sign libraries and load unsigned modules in a separate
context (as Ludo put it: why all this sophistication)

Quiting again Ludo

> This probably makes sense in the context that the copyright owner,
> Google, envisioned: presumably Android programs loading random
> proprietary modules coming from the app store.  But I wonder what the
> point is in the context of a free GNU/Linux distro.

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.

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.

Message #19 received at 72828 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jacopo Mondi <jacopo.mondi <at> ideasonboard.com>
Cc: 72828 <at> debbugs.gnu.org
Subject: Re: bug#72828: Grafting breaks libcamera signatures
Date: Wed, 04 Sep 2024 18:42:37 +0200

Hi Jacopo,

Jacopo Mondi <jacopo.mondi <at> 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).

Thanks for chiming in!

Ludo’.

Message #22 received at 72828 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Tropin <andrew <at> trop.in>
To: Ludovic Courtès <ludo <at> gnu.org>, Jacopo Mondi
 <jacopo.mondi <at> ideasonboard.com>
Cc: 72828 <at> debbugs.gnu.org
Subject: Re: bug#72828: Grafting breaks libcamera signatures
Date: Wed, 04 Sep 2024 21:42:17 +0400

[Message part 1 (text/plain, inline)]

On 2024-09-04 18:42, Ludovic Courtès wrote:

> Hi Jacopo,
>
> Jacopo Mondi <jacopo.mondi <at> 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:

[0001-libcamera-ipa_manager-Disable-signature-verification.patch (text/x-patch, inline)]

From c99706475cde3d963a17f4f8871149711ce6c467 Mon Sep 17 00:00:00 2001
From: Andrew Tropin <andrew <at> trop.in>
Date: Wed, 4 Sep 2024 21:36:16 +0400
Subject: [PATCH] libcamera: ipa_manager: Disable signature verification

---
 src/libcamera/ipa_manager.cpp | 28 +++++-----------------------
 1 file changed, 5 insertions(+), 23 deletions(-)

diff --git a/src/libcamera/ipa_manager.cpp b/src/libcamera/ipa_manager.cpp
index cfc24d38..4fd3cf3e 100644
--- a/src/libcamera/ipa_manager.cpp
+++ b/src/libcamera/ipa_manager.cpp
@@ -284,33 +284,15 @@ IPAModule *IPAManager::module(PipelineHandler *pipe, uint32_t minVersion,
 
 bool IPAManager::isSignatureValid([[maybe_unused]] IPAModule *ipa) const
 {
-#if HAVE_IPA_PUBKEY
-	char *force = utils::secure_getenv("LIBCAMERA_IPA_FORCE_ISOLATION");
-	if (force && force[0] != '\0') {
-		LOG(IPAManager, Debug)
-			<< "Isolation of IPA module " << ipa->path()
-			<< " forced through environment variable";
-		return false;
-	}
-
-	File file{ ipa->path() };
-	if (!file.open(File::OpenModeFlag::ReadOnly))
-		return false;
-
-	Span<uint8_t> data = file.map();
-	if (data.empty())
-		return false;
-
-	bool valid = pubKey_.verify(data, ipa->signature());
+	LOG(IPAManager, Debug)
+		<< "Signature verification is disabled by Guix. "
+		<< "See https://issues.guix.gnu.org/72828 for more details.";
 
 	LOG(IPAManager, Debug)
 		<< "IPA module " << ipa->path() << " signature is "
-		<< (valid ? "valid" : "not valid");
+		<< "not verified (verification skipped).";
 
-	return valid;
-#else
-	return false;
-#endif
+	return true;
 }
 
 } /* namespace libcamera */
-- 
2.45.2

[Message part 3 (text/plain, inline)]

Everyone is ok with it?

-- 
Best regards,
Andrew Tropin

[signature.asc (application/pgp-signature, inline)]

Message #27 received at 72828-done <at> debbugs.gnu.org (full text, mbox):

From: Andrew Tropin <andrew <at> trop.in>
To: Ludovic Courtès <ludo <at> gnu.org>, Jacopo Mondi
 <jacopo.mondi <at> ideasonboard.com>
Cc: 72828-done <at> debbugs.gnu.org
Subject: Re: bug#72828: Grafting breaks libcamera signatures
Date: Thu, 05 Sep 2024 10:46:03 +0400

[Message part 1 (text/plain, inline)]

On 2024-09-04 21:42, Andrew Tropin wrote:

> On 2024-09-04 18:42, Ludovic Courtès wrote:
>
>> Hi Jacopo,
>>
>> Jacopo Mondi <jacopo.mondi <at> 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:
>
> From c99706475cde3d963a17f4f8871149711ce6c467 Mon Sep 17 00:00:00 2001
> From: Andrew Tropin <andrew <at> trop.in>
> Date: Wed, 4 Sep 2024 21:36:16 +0400
> Subject: [PATCH] libcamera: ipa_manager: Disable signature verification
>
> ---
>  src/libcamera/ipa_manager.cpp | 28 +++++-----------------------
>  1 file changed, 5 insertions(+), 23 deletions(-)
>
> diff --git a/src/libcamera/ipa_manager.cpp b/src/libcamera/ipa_manager.cpp
> index cfc24d38..4fd3cf3e 100644
> --- a/src/libcamera/ipa_manager.cpp
> +++ b/src/libcamera/ipa_manager.cpp
> @@ -284,33 +284,15 @@ IPAModule *IPAManager::module(PipelineHandler *pipe, uint32_t minVersion,
>  
>  bool IPAManager::isSignatureValid([[maybe_unused]] IPAModule *ipa) const
>  {
> -#if HAVE_IPA_PUBKEY
> -	char *force = utils::secure_getenv("LIBCAMERA_IPA_FORCE_ISOLATION");
> -	if (force && force[0] != '\0') {
> -		LOG(IPAManager, Debug)
> -			<< "Isolation of IPA module " << ipa->path()
> -			<< " forced through environment variable";
> -		return false;
> -	}
> -
> -	File file{ ipa->path() };
> -	if (!file.open(File::OpenModeFlag::ReadOnly))
> -		return false;
> -
> -	Span<uint8_t> data = file.map();
> -	if (data.empty())
> -		return false;
> -
> -	bool valid = pubKey_.verify(data, ipa->signature());
> +	LOG(IPAManager, Debug)
> +		<< "Signature verification is disabled by Guix. "
> +		<< "See https://issues.guix.gnu.org/72828 for more details.";
>  
>  	LOG(IPAManager, Debug)
>  		<< "IPA module " << ipa->path() << " signature is "
> -		<< (valid ? "valid" : "not valid");
> +		<< "not verified (verification skipped).";
>  
> -	return valid;
> -#else
> -	return false;
> -#endif
> +	return true;
>  }
>  
>  } /* namespace libcamera */
> -- 
> 2.45.2
>
>
> Everyone is ok with it?

I've disabled signature verification, tested with cam -l and qcam, it
works good so far, will check browsers and pipewire after ci finish
building them.

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b0e224566f

Thank you everyone for participating, it helped a lot in narrowing down
and fixing the problem!  

Marking issue as DONE.

I'll update corresponding ticket on libcamera bugtracker after I test
the rest of applications.

-- 
Best regards,
Andrew Tropin

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 72828 <at> debbugs.gnu.org (full text, mbox):

From: Jacopo Mondi <jacopo.mondi <at> ideasonboard.com>
To: Andrew Tropin <andrew <at> trop.in>
Cc: Jacopo Mondi <jacopo.mondi <at> ideasonboard.com>, 72828 <at> debbugs.gnu.org,
 Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#72828: Grafting breaks libcamera signatures
Date: Thu, 5 Sep 2024 08:56:54 +0200

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.