[{"id":13660,"web_url":"https://patchwork.libcamera.org/comment/13660/","msgid":"","date":"2020-11-10T10:08:53","subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","submitter":{"id":9,"url":"https://patchwork.libcamera.org/api/people/9/","name":"Tomasz Figa","email":"tfiga@chromium.org"},"content":"Hi Niklas,\n\nOn Mon, Nov 9, 2020 at 10:17 AM Niklas Söderlund\n wrote:\n>\n> Libcamera signs its IPA modules (.so files) after they are built. The\n> signature is later verified when loading the IPA modules and if they do\n> not match the IPA is treated as a untrusted module. The CrOS build\n> system by default strips all binaries after the build step and modify\n> the IPA .so files in so they fail the signature check.\n>\n> The build system inject hooks after the post_src_install hook that\n> strips binaries and creates the packet that is installed on target. It\n> is therefor not possible to to generate the IPA module signature for the\n> stripped modules without also packeting the private key and doing so in\n> pre_pkg_preinst. Stripping and generating signatures for the IPA .so\n> files in src_install is not possible as the exact method for stripping\n> them may differ between the ebuild and the build system hook.\n>\n> Safest route is to never stripp the IPA modules. Instead of restricting\n> stripping of all libcamera binaries use dostrip to only disable\n> stripping of the IPA modules. The EAPI needs to be increased to version\n> 7 to support dostrip.\n>\n\nCould we just disable the extra signing and signature verification on\nChrome OS? We have integrity enforced for the whole file system by\ndm-verity, so there is no need to verify anything in particular\ncomponents of the stack anymore.\n\nBest regards,\nTomasz\n\n> Signed-off-by: Niklas Söderlund \n> ---\n> media-libs/libcamera/libcamera-9999.ebuild | 4 +++-\n> 1 file changed, 3 insertions(+), 1 deletion(-)\n>\n> diff --git a/media-libs/libcamera/libcamera-9999.ebuild b/media-libs/libcamera/libcamera-9999.ebuild\n> index 57ff00337309f30c..ce4183a89ef095de 100644\n> --- a/media-libs/libcamera/libcamera-9999.ebuild\n> +++ b/media-libs/libcamera/libcamera-9999.ebuild\n> @@ -1,7 +1,7 @@\n> # Copyright 2019 The Chromium OS Authors. All rights reserved.\n> # Distributed under the terms of the GNU General Public License v2\n>\n> -EAPI=6\n> +EAPI=7\n>\n> CROS_WORKON_PROJECT=\"chromiumos/third_party/libcamera\"\n> CROS_WORKON_INCREMENTAL_BUILD=\"1\"\n> @@ -49,4 +49,6 @@ src_install() {\n> meson_src_install\n>\n> dosym ../libcamera.so \"/usr/$(get_libdir)/camera_hal/libcamera.so\"\n> +\n> + dostrip -x /usr/$(get_libdir)/libcamera/\n> }\n> --\n> 2.25.1\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id A6BBFBE082\n\tfor ;\n\tTue, 10 Nov 2020 10:09:07 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 43F39630BE;\n\tTue, 10 Nov 2020 11:09:07 +0100 (CET)","from mail-ed1-x541.google.com (mail-ed1-x541.google.com\n\t[IPv6:2a00:1450:4864:20::541])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A75BD630BA\n\tfor ;\n\tTue, 10 Nov 2020 11:09:05 +0100 (CET)","by mail-ed1-x541.google.com with SMTP id q3so12051123edr.12\n\tfor ;\n\tTue, 10 Nov 2020 02:09:05 -0800 (PST)","from mail-wm1-f51.google.com (mail-wm1-f51.google.com.\n\t[209.85.128.51]) by smtp.gmail.com with ESMTPSA id\n\tg20sm5545748ejk.3.2020.11.10.02.09.04\n\tfor \n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tTue, 10 Nov 2020 02:09:04 -0800 (PST)","by mail-wm1-f51.google.com with SMTP id a3so1096832wmb.5\n\tfor ;\n\tTue, 10 Nov 2020 02:09:04 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"XSJw5K2k\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org;\n\ts=google; \n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=ZK7Kws22YBZPi+jJeyfVX0jCDQp6iFpfkGc5w6OelTo=;\n\tb=XSJw5K2k5kdJ8+g4KQ1M/xhNye/9STEjMFWOtHsvIMnFocG7YEWuGzRMcVtoTbgKD5\n\tM0PT/5knIsAKFYYAwZoE4Ov7mqq39fUGJiEFrpseqosRvEVMugBhxRHJXEfdX/MMUq1w\n\t9YBDqeSjm/P/AsvRIAJVqqmnTp3ljBM8KiXmE=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=ZK7Kws22YBZPi+jJeyfVX0jCDQp6iFpfkGc5w6OelTo=;\n\tb=HEJD3fKPWy/q4/V8tXAi5L9HMoIBv14rWbwBoD/ucJf/d9vqITJoPTXNF++YYYdXCd\n\tFGEe/JMBv1pCDya04nVkP3OkbBR+80BFJVWONwkeEQuf7ZTMRhbbWlc4uK2N+jSYj70j\n\tP+EjpOploq/6K4dU++6RIuMmqGX9L4Xl1QS1f/88Eyd7L5FqayIbYAaTTPrXHb2Eg4Iz\n\ty7fULGT98P9R0hFVN46gICJcT2TiksLJ/8u6R+eA5GBpZsUqMVkzdonLKEGDpgS3iScj\n\tF1reyR+cMXXS/8b0eISP/6JeEDlozed5UT/pzYG61fGewsNk28FUo1urmPAMmWK88C9P\n\t9LFw==","X-Gm-Message-State":"AOAM532TAWmf8dMQi4EtVHxQEwiO5UFcZYQIScmn8+kDEk8uSpxFQIS6\n\tWc60LAPkAikXohpWyd8f7J32M6G8sn7jjice","X-Google-Smtp-Source":"ABdhPJzGUVuG1Ash1PLGurzCqSIhFhWZrxvvK3Y3EOCscdQV0TluV+L+BoWUeNXWSrsChnRF73s0VQ==","X-Received":["by 2002:a50:dec5:: with SMTP id\n\td5mr20593082edl.362.1605002945129; \n\tTue, 10 Nov 2020 02:09:05 -0800 (PST)","by 2002:a1c:9a12:: with SMTP id c18mr3852742wme.22.1605002944056;\n\tTue, 10 Nov 2020 02:09:04 -0800 (PST)"],"MIME-Version":"1.0","References":"<20201109011656.2560957-1-niklas.soderlund@ragnatech.se>\n\t<20201109011656.2560957-3-niklas.soderlund@ragnatech.se>","In-Reply-To":"<20201109011656.2560957-3-niklas.soderlund@ragnatech.se>","From":"Tomasz Figa ","Date":"Tue, 10 Nov 2020 19:08:53 +0900","X-Gmail-Original-Message-ID":"","Message-ID":"","To":"=?utf-8?q?Niklas_S=C3=B6derlund?= ","Subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":13936,"web_url":"https://patchwork.libcamera.org/comment/13936/","msgid":"<20201126163300.GZ3905@pendragon.ideasonboard.com>","date":"2020-11-26T16:33:00","subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Tomasz,\n\nOn Tue, Nov 10, 2020 at 07:08:53PM +0900, Tomasz Figa wrote:\n> On Mon, Nov 9, 2020 at 10:17 AM Niklas Söderlund wrote:\n> >\n> > Libcamera signs its IPA modules (.so files) after they are built. The\n> > signature is later verified when loading the IPA modules and if they do\n> > not match the IPA is treated as a untrusted module. The CrOS build\n> > system by default strips all binaries after the build step and modify\n> > the IPA .so files in so they fail the signature check.\n> >\n> > The build system inject hooks after the post_src_install hook that\n> > strips binaries and creates the packet that is installed on target. It\n> > is therefor not possible to to generate the IPA module signature for the\n> > stripped modules without also packeting the private key and doing so in\n> > pre_pkg_preinst. Stripping and generating signatures for the IPA .so\n> > files in src_install is not possible as the exact method for stripping\n> > them may differ between the ebuild and the build system hook.\n> >\n> > Safest route is to never stripp the IPA modules. Instead of restricting\n> > stripping of all libcamera binaries use dostrip to only disable\n> > stripping of the IPA modules. The EAPI needs to be increased to version\n> > 7 to support dostrip.\n> \n> Could we just disable the extra signing and signature verification on\n> Chrome OS? We have integrity enforced for the whole file system by\n> dm-verity, so there is no need to verify anything in particular\n> components of the stack anymore.\n\nThe signature mechanism is how we decide if an IPA module has to be\nisolated. Once Paul's IPA IPC series gets merged, we could disable it\nindeed, which would force isolation of all IPA modules, even the\nopen-source ones. Is that desired though ?\n\n> > Signed-off-by: Niklas Söderlund \n> > ---\n> > media-libs/libcamera/libcamera-9999.ebuild | 4 +++-\n> > 1 file changed, 3 insertions(+), 1 deletion(-)\n> >\n> > diff --git a/media-libs/libcamera/libcamera-9999.ebuild b/media-libs/libcamera/libcamera-9999.ebuild\n> > index 57ff00337309f30c..ce4183a89ef095de 100644\n> > --- a/media-libs/libcamera/libcamera-9999.ebuild\n> > +++ b/media-libs/libcamera/libcamera-9999.ebuild\n> > @@ -1,7 +1,7 @@\n> > # Copyright 2019 The Chromium OS Authors. All rights reserved.\n> > # Distributed under the terms of the GNU General Public License v2\n> >\n> > -EAPI=6\n> > +EAPI=7\n> >\n> > CROS_WORKON_PROJECT=\"chromiumos/third_party/libcamera\"\n> > CROS_WORKON_INCREMENTAL_BUILD=\"1\"\n> > @@ -49,4 +49,6 @@ src_install() {\n> > meson_src_install\n> >\n> > dosym ../libcamera.so \"/usr/$(get_libdir)/camera_hal/libcamera.so\"\n> > +\n> > + dostrip -x /usr/$(get_libdir)/libcamera/\n> > }","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 55E2DBE176\n\tfor ;\n\tThu, 26 Nov 2020 16:33:11 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id E46166347E;\n\tThu, 26 Nov 2020 17:33:10 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id AF6A86346B\n\tfor ;\n\tThu, 26 Nov 2020 17:33:09 +0100 (CET)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 2932EA1B;\n\tThu, 26 Nov 2020 17:33:09 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"tAsrd552\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1606408389;\n\tbh=IuIPg7cHKBcQO9NBWhTg82eNw8fJBoYNeFEt4Gh320c=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=tAsrd552U4K1chClmL+u7odiPMLmvZ53fvA+5YANN2Xd+7b3gSWPPNtnxSNpbmuvR\n\tfnPavEioE4H9zK6Ufkfin/DbubPfHs1fW2UnKJq2YHAz6Dz0Kf8cRwpHmHGGat4aFe\n\tDaDTTS6sCMlPTj/GNcHZaQj25uiR/hGtjdkrsg0o=","Date":"Thu, 26 Nov 2020 18:33:00 +0200","From":"Laurent Pinchart ","To":"Tomasz Figa ","Message-ID":"<20201126163300.GZ3905@pendragon.ideasonboard.com>","References":"<20201109011656.2560957-1-niklas.soderlund@ragnatech.se>\n\t<20201109011656.2560957-3-niklas.soderlund@ragnatech.se>\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":13937,"web_url":"https://patchwork.libcamera.org/comment/13937/","msgid":"","date":"2020-11-26T16:39:40","subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","submitter":{"id":9,"url":"https://patchwork.libcamera.org/api/people/9/","name":"Tomasz Figa","email":"tfiga@chromium.org"},"content":"On Fri, Nov 27, 2020 at 1:33 AM Laurent Pinchart\n wrote:\n>\n> Hi Tomasz,\n>\n> On Tue, Nov 10, 2020 at 07:08:53PM +0900, Tomasz Figa wrote:\n> > On Mon, Nov 9, 2020 at 10:17 AM Niklas Söderlund wrote:\n> > >\n> > > Libcamera signs its IPA modules (.so files) after they are built. The\n> > > signature is later verified when loading the IPA modules and if they do\n> > > not match the IPA is treated as a untrusted module. The CrOS build\n> > > system by default strips all binaries after the build step and modify\n> > > the IPA .so files in so they fail the signature check.\n> > >\n> > > The build system inject hooks after the post_src_install hook that\n> > > strips binaries and creates the packet that is installed on target. It\n> > > is therefor not possible to to generate the IPA module signature for the\n> > > stripped modules without also packeting the private key and doing so in\n> > > pre_pkg_preinst. Stripping and generating signatures for the IPA .so\n> > > files in src_install is not possible as the exact method for stripping\n> > > them may differ between the ebuild and the build system hook.\n> > >\n> > > Safest route is to never stripp the IPA modules. Instead of restricting\n> > > stripping of all libcamera binaries use dostrip to only disable\n> > > stripping of the IPA modules. The EAPI needs to be increased to version\n> > > 7 to support dostrip.\n> >\n> > Could we just disable the extra signing and signature verification on\n> > Chrome OS? We have integrity enforced for the whole file system by\n> > dm-verity, so there is no need to verify anything in particular\n> > components of the stack anymore.\n>\n> The signature mechanism is how we decide if an IPA module has to be\n> isolated. Once Paul's IPA IPC series gets merged, we could disable it\n> indeed, which would force isolation of all IPA modules, even the\n> open-source ones. Is that desired though ?\n\nCould you elaborate a bit more how we decide whether to isolate or not\nbased on this? I'd assume there would be integrators willing to run\nout of tree IPAs (which could be still open source) without isolation.\n\n>\n> > > Signed-off-by: Niklas Söderlund \n> > > ---\n> > > media-libs/libcamera/libcamera-9999.ebuild | 4 +++-\n> > > 1 file changed, 3 insertions(+), 1 deletion(-)\n> > >\n> > > diff --git a/media-libs/libcamera/libcamera-9999.ebuild b/media-libs/libcamera/libcamera-9999.ebuild\n> > > index 57ff00337309f30c..ce4183a89ef095de 100644\n> > > --- a/media-libs/libcamera/libcamera-9999.ebuild\n> > > +++ b/media-libs/libcamera/libcamera-9999.ebuild\n> > > @@ -1,7 +1,7 @@\n> > > # Copyright 2019 The Chromium OS Authors. All rights reserved.\n> > > # Distributed under the terms of the GNU General Public License v2\n> > >\n> > > -EAPI=6\n> > > +EAPI=7\n> > >\n> > > CROS_WORKON_PROJECT=\"chromiumos/third_party/libcamera\"\n> > > CROS_WORKON_INCREMENTAL_BUILD=\"1\"\n> > > @@ -49,4 +49,6 @@ src_install() {\n> > > meson_src_install\n> > >\n> > > dosym ../libcamera.so \"/usr/$(get_libdir)/camera_hal/libcamera.so\"\n> > > +\n> > > + dostrip -x /usr/$(get_libdir)/libcamera/\n> > > }\n>\n> --\n> Regards,\n>\n> Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 47376BE08A\n\tfor ;\n\tThu, 26 Nov 2020 16:39:57 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id BDADF6347E;\n\tThu, 26 Nov 2020 17:39:56 +0100 (CET)","from mail-ed1-x541.google.com (mail-ed1-x541.google.com\n\t[IPv6:2a00:1450:4864:20::541])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id C8E726346B\n\tfor ;\n\tThu, 26 Nov 2020 17:39:54 +0100 (CET)","by mail-ed1-x541.google.com with SMTP id k1so2874814eds.13\n\tfor ;\n\tThu, 26 Nov 2020 08:39:54 -0800 (PST)","from mail-wr1-f42.google.com (mail-wr1-f42.google.com.\n\t[209.85.221.42]) by smtp.gmail.com with ESMTPSA id\n\tov32sm3382042ejb.123.2020.11.26.08.39.52\n\tfor \n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tThu, 26 Nov 2020 08:39:53 -0800 (PST)","by mail-wr1-f42.google.com with SMTP id e7so2793212wrv.6\n\tfor ;\n\tThu, 26 Nov 2020 08:39:52 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"Zo3IRyrq\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org;\n\ts=google; \n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=k3PbeEQL4a74h3OwciO2gz8j1MumJxU5YP5FEsDm1eA=;\n\tb=Zo3IRyrqA4MWc80Y1EME7rWbGoQNdPGobnA5AnLS8wrbNGUAsMG8Y6B2gGkt52/BvI\n\th7++39Y4O5kaUJwdkvLExrYXHK2fUE95trqI368VmaXYpU5zvAlzIS5rZhqIMsBJd5Kj\n\ty79JZHPlC5/aWuqWwg3qcUeKlWP1TQ7C2p9Ic=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=k3PbeEQL4a74h3OwciO2gz8j1MumJxU5YP5FEsDm1eA=;\n\tb=hjX+JUi292WrTc38m+mFXczwtGH+1zqh86sPUfB9czrz1wmhgjdxDMRV5KvJr9PAr1\n\tlF2pZLLQ15lE3TExtDVUOrpnUKVFlDFLI/H7fNmwEncG7DzTXae0G8RXQjdna1aNGrCG\n\tLcWi0AKDqcWLgQ8MLPNWn8jagVdcjsVCu0sB+lF6N/nvTWlokq2kEPvbb7ujgIXmWhMu\n\t+fyCgf5gIriYsJwdvM8g93zht2RHMwNsaADUIu9+pN3f0i7x8P8qUUUMJjcBNnO02L0J\n\tgWlnZ/EJ5QIMiKVC8a4cmZUWnaOurJ/WE15geqrSiw6OjTMS9VzCmbrM4xPe7A8bj9RS\n\tPG+w==","X-Gm-Message-State":"AOAM533yREGw5YJ96jgcrLm30e7NhsiM9iipl9/0rERX5xWmJSEPSpWG\n\tllLsrpQX2Sj2LSqanCQCIS+sewPRW4IvLw==","X-Google-Smtp-Source":"ABdhPJxGo5ZasvoFjndRQVdgFSEESZjedlj//5ANZvBTaqV0A65Ij5HNPP2zqSBEx05ofndfdTusrg==","X-Received":["by 2002:aa7:cad2:: with SMTP id\n\tl18mr3316023edt.183.1606408794166; \n\tThu, 26 Nov 2020 08:39:54 -0800 (PST)","by 2002:adf:fb90:: with SMTP id\n\ta16mr4866570wrr.192.1606408792540; \n\tThu, 26 Nov 2020 08:39:52 -0800 (PST)"],"MIME-Version":"1.0","References":"<20201109011656.2560957-1-niklas.soderlund@ragnatech.se>\n\t<20201109011656.2560957-3-niklas.soderlund@ragnatech.se>\n\t\n\t<20201126163300.GZ3905@pendragon.ideasonboard.com>","In-Reply-To":"<20201126163300.GZ3905@pendragon.ideasonboard.com>","From":"Tomasz Figa ","Date":"Fri, 27 Nov 2020 01:39:40 +0900","X-Gmail-Original-Message-ID":"","Message-ID":"","To":"Laurent Pinchart ","Subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":14065,"web_url":"https://patchwork.libcamera.org/comment/14065/","msgid":"<20201204234313.GN4109@pendragon.ideasonboard.com>","date":"2020-12-04T23:43:13","subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Tomasz,\n\nOn Fri, Nov 27, 2020 at 01:39:40AM +0900, Tomasz Figa wrote:\n> On Fri, Nov 27, 2020 at 1:33 AM Laurent Pinchart wrote:\n> > On Tue, Nov 10, 2020 at 07:08:53PM +0900, Tomasz Figa wrote:\n> > > On Mon, Nov 9, 2020 at 10:17 AM Niklas Söderlund wrote:\n> > > >\n> > > > Libcamera signs its IPA modules (.so files) after they are built. The\n> > > > signature is later verified when loading the IPA modules and if they do\n> > > > not match the IPA is treated as a untrusted module. The CrOS build\n> > > > system by default strips all binaries after the build step and modify\n> > > > the IPA .so files in so they fail the signature check.\n> > > >\n> > > > The build system inject hooks after the post_src_install hook that\n> > > > strips binaries and creates the packet that is installed on target. It\n> > > > is therefor not possible to to generate the IPA module signature for the\n> > > > stripped modules without also packeting the private key and doing so in\n> > > > pre_pkg_preinst. Stripping and generating signatures for the IPA .so\n> > > > files in src_install is not possible as the exact method for stripping\n> > > > them may differ between the ebuild and the build system hook.\n> > > >\n> > > > Safest route is to never stripp the IPA modules. Instead of restricting\n> > > > stripping of all libcamera binaries use dostrip to only disable\n> > > > stripping of the IPA modules. The EAPI needs to be increased to version\n> > > > 7 to support dostrip.\n> > >\n> > > Could we just disable the extra signing and signature verification on\n> > > Chrome OS? We have integrity enforced for the whole file system by\n> > > dm-verity, so there is no need to verify anything in particular\n> > > components of the stack anymore.\n> >\n> > The signature mechanism is how we decide if an IPA module has to be\n> > isolated. Once Paul's IPA IPC series gets merged, we could disable it\n> > indeed, which would force isolation of all IPA modules, even the\n> > open-source ones. Is that desired though ?\n> \n> Could you elaborate a bit more how we decide whether to isolate or not\n> based on this? I'd assume there would be integrators willing to run\n> out of tree IPAs (which could be still open source) without isolation.\n\nAt the moment, we isolate all IPA modules that don't provide a valid\nsignature. In-tree modules are signed during the build process, and are\nthus run without isolation (but in a separate thread, to replicate the\nasynchronous communication mechanism of the isolated case, in order to\navoid too many differences between the two cases). Out-of-tree modules\nare not signed, and are thus isolated.\n\nWe expect this mechanism to be extended with some or all of the\nfollowing:\n\n- A flag in the module information structure to force isolated\n execution. This would be set, for instance, by the wrapper module for\n the IPU3 that loads the Intel binaries, even if the module is in-tree\n (we haven't decided on whether that will be the case though) and thus\n gets signed.\n\n- A similar mechanism that forces isolation of modules listed in a\n configuration file.\n\n- A method to save the private key at build time, to sign modules built\n out of tree. This could be used by Linux distributions to update IPA\n modules without having to update libcamera itself. We may also update\n the build process to import a public/private key pair instead of\n generating one.\n\nIt will ultimately be an integrator decision, as integrators will in any\ncase have the option of carrying local modifications to libcamera that\nchanges the IPA module loading and isolation mechanism. Changes that\nmake sense upstream should of course be merged in our tree.\n\nNote that we also foresee changes in the isolation mechanism, at least\nfor Chrome OS, but possibly globally, to use an algorithm daemon. I\nwould however prefer not implementing this right now as we have more\nurgent tasks to focus on.\n\n> > > > Signed-off-by: Niklas Söderlund \n> > > > ---\n> > > > media-libs/libcamera/libcamera-9999.ebuild | 4 +++-\n> > > > 1 file changed, 3 insertions(+), 1 deletion(-)\n> > > >\n> > > > diff --git a/media-libs/libcamera/libcamera-9999.ebuild b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > index 57ff00337309f30c..ce4183a89ef095de 100644\n> > > > --- a/media-libs/libcamera/libcamera-9999.ebuild\n> > > > +++ b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > @@ -1,7 +1,7 @@\n> > > > # Copyright 2019 The Chromium OS Authors. All rights reserved.\n> > > > # Distributed under the terms of the GNU General Public License v2\n> > > >\n> > > > -EAPI=6\n> > > > +EAPI=7\n> > > >\n> > > > CROS_WORKON_PROJECT=\"chromiumos/third_party/libcamera\"\n> > > > CROS_WORKON_INCREMENTAL_BUILD=\"1\"\n> > > > @@ -49,4 +49,6 @@ src_install() {\n> > > > meson_src_install\n> > > >\n> > > > dosym ../libcamera.so \"/usr/$(get_libdir)/camera_hal/libcamera.so\"\n> > > > +\n> > > > + dostrip -x /usr/$(get_libdir)/libcamera/\n> > > > }","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 7C40CBE176\n\tfor ;\n\tFri, 4 Dec 2020 23:43:18 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 080A9635EF;\n\tSat, 5 Dec 2020 00:43:18 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 94109635DC\n\tfor ;\n\tSat, 5 Dec 2020 00:43:15 +0100 (CET)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 0C46C99A;\n\tSat, 5 Dec 2020 00:43:14 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"PwgEHpxL\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1607125395;\n\tbh=gwB/kH22US++6v/8ONtu2X2ET+vF5f1qEfebTS2nr3k=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=PwgEHpxLR8r5idPJXO2fU6bmjDogKFASC9wQUkPDsxCg7cIsWw9SUPqvsKrU9xODa\n\tQPi30J9xrKpVGsPKvYtTxcjHu18lG2PVzSwpUz40xeTfgaWRVKnolKKZFxFhBKDf51\n\tCdDnP0WM3+F5zzhdyukJxZTNVx1+B1E4vKPdKHl8=","Date":"Sat, 5 Dec 2020 01:43:13 +0200","From":"Laurent Pinchart ","To":"Tomasz Figa ","Message-ID":"<20201204234313.GN4109@pendragon.ideasonboard.com>","References":"<20201109011656.2560957-1-niklas.soderlund@ragnatech.se>\n\t<20201109011656.2560957-3-niklas.soderlund@ragnatech.se>\n\t\n\t<20201126163300.GZ3905@pendragon.ideasonboard.com>\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":14075,"web_url":"https://patchwork.libcamera.org/comment/14075/","msgid":"<20201205092019.GA2203197@oden.dyn.berto.se>","date":"2020-12-05T09:20:19","subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","submitter":{"id":5,"url":"https://patchwork.libcamera.org/api/people/5/","name":"Niklas Söderlund","email":"niklas.soderlund@ragnatech.se"},"content":"Hello Laurent and Tomasz,\n\nOn 2020-12-05 01:43:13 +0200, Laurent Pinchart wrote:\n> Hi Tomasz,\n> \n> On Fri, Nov 27, 2020 at 01:39:40AM +0900, Tomasz Figa wrote:\n> > On Fri, Nov 27, 2020 at 1:33 AM Laurent Pinchart wrote:\n> > > On Tue, Nov 10, 2020 at 07:08:53PM +0900, Tomasz Figa wrote:\n> > > > On Mon, Nov 9, 2020 at 10:17 AM Niklas Söderlund wrote:\n> > > > >\n> > > > > Libcamera signs its IPA modules (.so files) after they are built. The\n> > > > > signature is later verified when loading the IPA modules and if they do\n> > > > > not match the IPA is treated as a untrusted module. The CrOS build\n> > > > > system by default strips all binaries after the build step and modify\n> > > > > the IPA .so files in so they fail the signature check.\n> > > > >\n> > > > > The build system inject hooks after the post_src_install hook that\n> > > > > strips binaries and creates the packet that is installed on target. It\n> > > > > is therefor not possible to to generate the IPA module signature for the\n> > > > > stripped modules without also packeting the private key and doing so in\n> > > > > pre_pkg_preinst. Stripping and generating signatures for the IPA .so\n> > > > > files in src_install is not possible as the exact method for stripping\n> > > > > them may differ between the ebuild and the build system hook.\n> > > > >\n> > > > > Safest route is to never stripp the IPA modules. Instead of restricting\n> > > > > stripping of all libcamera binaries use dostrip to only disable\n> > > > > stripping of the IPA modules. The EAPI needs to be increased to version\n> > > > > 7 to support dostrip.\n> > > >\n> > > > Could we just disable the extra signing and signature verification on\n> > > > Chrome OS? We have integrity enforced for the whole file system by\n> > > > dm-verity, so there is no need to verify anything in particular\n> > > > components of the stack anymore.\n> > >\n> > > The signature mechanism is how we decide if an IPA module has to be\n> > > isolated. Once Paul's IPA IPC series gets merged, we could disable it\n> > > indeed, which would force isolation of all IPA modules, even the\n> > > open-source ones. Is that desired though ?\n> > \n> > Could you elaborate a bit more how we decide whether to isolate or not\n> > based on this? I'd assume there would be integrators willing to run\n> > out of tree IPAs (which could be still open source) without isolation.\n> \n> At the moment, we isolate all IPA modules that don't provide a valid\n> signature. In-tree modules are signed during the build process, and are\n> thus run without isolation (but in a separate thread, to replicate the\n> asynchronous communication mechanism of the isolated case, in order to\n> avoid too many differences between the two cases). Out-of-tree modules\n> are not signed, and are thus isolated.\n> \n> We expect this mechanism to be extended with some or all of the\n> following:\n> \n> - A flag in the module information structure to force isolated\n> execution. This would be set, for instance, by the wrapper module for\n> the IPU3 that loads the Intel binaries, even if the module is in-tree\n> (we haven't decided on whether that will be the case though) and thus\n> gets signed.\n> \n> - A similar mechanism that forces isolation of modules listed in a\n> configuration file.\n> \n> - A method to save the private key at build time, to sign modules built\n> out of tree. This could be used by Linux distributions to update IPA\n> modules without having to update libcamera itself. We may also update\n> the build process to import a public/private key pair instead of\n> generating one.\n\nQuick note: Storing the generated key and signing modules at packet \ninstall time is one of the possible solutions for CrOS that could be \nadded with little effort. I was reluctant to it as it feels a bit \nredundant to ship the things that should be signed together with the \nsigning key ;-) It would however allow us to sign the IPA's after the \nCrOS striping of the binaries at packet creation time as we could resign \nthem when they are installed on target.\n\n> \n> It will ultimately be an integrator decision, as integrators will in any\n> case have the option of carrying local modifications to libcamera that\n> changes the IPA module loading and isolation mechanism. Changes that\n> make sense upstream should of course be merged in our tree.\n> \n> Note that we also foresee changes in the isolation mechanism, at least\n> for Chrome OS, but possibly globally, to use an algorithm daemon. I\n> would however prefer not implementing this right now as we have more\n> urgent tasks to focus on.\n> \n> > > > > Signed-off-by: Niklas Söderlund \n> > > > > ---\n> > > > > media-libs/libcamera/libcamera-9999.ebuild | 4 +++-\n> > > > > 1 file changed, 3 insertions(+), 1 deletion(-)\n> > > > >\n> > > > > diff --git a/media-libs/libcamera/libcamera-9999.ebuild b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > index 57ff00337309f30c..ce4183a89ef095de 100644\n> > > > > --- a/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > +++ b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > @@ -1,7 +1,7 @@\n> > > > > # Copyright 2019 The Chromium OS Authors. All rights reserved.\n> > > > > # Distributed under the terms of the GNU General Public License v2\n> > > > >\n> > > > > -EAPI=6\n> > > > > +EAPI=7\n> > > > >\n> > > > > CROS_WORKON_PROJECT=\"chromiumos/third_party/libcamera\"\n> > > > > CROS_WORKON_INCREMENTAL_BUILD=\"1\"\n> > > > > @@ -49,4 +49,6 @@ src_install() {\n> > > > > meson_src_install\n> > > > >\n> > > > > dosym ../libcamera.so \"/usr/$(get_libdir)/camera_hal/libcamera.so\"\n> > > > > +\n> > > > > + dostrip -x /usr/$(get_libdir)/libcamera/\n> > > > > }\n> \n> -- \n> Regards,\n> \n> Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id B36B1BDB1F\n\tfor ;\n\tSat, 5 Dec 2020 09:20:24 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 8403A635F2;\n\tSat, 5 Dec 2020 10:20:24 +0100 (CET)","from mail-lf1-x144.google.com (mail-lf1-x144.google.com\n\t[IPv6:2a00:1450:4864:20::144])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 2E04560327\n\tfor ;\n\tSat, 5 Dec 2020 10:20:23 +0100 (CET)","by mail-lf1-x144.google.com with SMTP id q13so11054047lfr.10\n\tfor ;\n\tSat, 05 Dec 2020 01:20:23 -0800 (PST)","from localhost (h-209-203.A463.priv.bahnhof.se. [155.4.209.203])\n\tby smtp.gmail.com with ESMTPSA id\n\tj69sm2223450lfj.49.2020.12.05.01.20.20\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tSat, 05 Dec 2020 01:20:20 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=ragnatech-se.20150623.gappssmtp.com\n\theader.i=@ragnatech-se.20150623.gappssmtp.com\n\theader.b=\"qT22Uw0j\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ragnatech-se.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:content-transfer-encoding:in-reply-to;\n\tbh=BA8FC/jlGFlVE6QA59ftabqrEPU9OpGHoE87Jutw9K8=;\n\tb=qT22Uw0j7DLm1dZ7toq0D3BSf3DPX2mQ69EbIZxbOc8pKsoSA0h2lhonJOVQdvC8om\n\tEXx6KVTtvzS9rM5A4xcZZLe9XjaglwTe9C3LWbKBAqca4BkkD6AsJMZpKQlDsgAEmeGf\n\tj5jOoTu38CnHm5BhRSay+9uzm4Mxrm1lkqDsu3ngiGqL1j5UqShrGpxagDI+7ICFVOBm\n\ttcpKedPdD20wySnjkadnDWDFZ4ajP5u2wMstPlr0nT0nNylafiz3pVqgGz4gCVHe6ElG\n\toTb34fCv28TKddDlL5PVHC6nAfIZVIK62BKvsZdwc9MByFG8jQZkVgJHT73KqhP5+qhZ\n\t9OEg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to;\n\tbh=BA8FC/jlGFlVE6QA59ftabqrEPU9OpGHoE87Jutw9K8=;\n\tb=mxm50nhPewjLlENaJv8bxgW/6jrAyl+KO7rmmlGxVySbXqhX4+JJnETMCX0wxt0uz8\n\tgQ7IAFBaRXkDo+pSmqKV5udPUh+XDXWdn3q2vUsJopw0wRJyfKGrTvjlUmvqbWkvKCoa\n\tofkrZxoq4vTqn4p+eFw+tvYhTWaIj+tBggg2IrYvoZnDNIFWVdI8qNToxgtUXtJI5WNs\n\t9ueTGhzaa95qmfrfPK6CSaVItMuAppj7mRcv2pOePy/Tq3i/t+/MZvsCy4Ij+UjqZyKX\n\tyVHgrASf+14U77+/4zmUbE0Nq9XWYyTtYDcs0nMN4Yl3hVlIEku3FkCkJELYeXKhaAyz\n\t0NTg==","X-Gm-Message-State":"AOAM531hf2N9ehm0CKw6kGrktLASCWQ9BfoKKAif2+YV/MpsnZLEr5tW\n\tLhBn0drkqsboVzJFDDERlwbz6A==","X-Google-Smtp-Source":"ABdhPJzxtb3TQ+MOEQmsHmP2Vx5jPYc1SlOsZDXsLgLfs8XMDboJEE3TU59c9vwd4uPmW6IR1TJyVw==","X-Received":"by 2002:ac2:54ab:: with SMTP id\n\tw11mr2763547lfk.107.1607160022310; \n\tSat, 05 Dec 2020 01:20:22 -0800 (PST)","Date":"Sat, 5 Dec 2020 10:20:19 +0100","From":"Niklas =?iso-8859-1?q?S=F6derlund?= ","To":"Laurent Pinchart ","Message-ID":"<20201205092019.GA2203197@oden.dyn.berto.se>","References":"<20201109011656.2560957-1-niklas.soderlund@ragnatech.se>\n\t<20201109011656.2560957-3-niklas.soderlund@ragnatech.se>\n\t\n\t<20201126163300.GZ3905@pendragon.ideasonboard.com>\n\t\n\t<20201204234313.GN4109@pendragon.ideasonboard.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20201204234313.GN4109@pendragon.ideasonboard.com>","Subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":14076,"web_url":"https://patchwork.libcamera.org/comment/14076/","msgid":"","date":"2020-12-05T14:15:35","subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Niklas,\n\nOn Sat, Dec 05, 2020 at 10:20:19AM +0100, Niklas Söderlund wrote:\n> On 2020-12-05 01:43:13 +0200, Laurent Pinchart wrote:\n> > On Fri, Nov 27, 2020 at 01:39:40AM +0900, Tomasz Figa wrote:\n> > > On Fri, Nov 27, 2020 at 1:33 AM Laurent Pinchart wrote:\n> > > > On Tue, Nov 10, 2020 at 07:08:53PM +0900, Tomasz Figa wrote:\n> > > > > On Mon, Nov 9, 2020 at 10:17 AM Niklas Söderlund wrote:\n> > > > > >\n> > > > > > Libcamera signs its IPA modules (.so files) after they are built. The\n> > > > > > signature is later verified when loading the IPA modules and if they do\n> > > > > > not match the IPA is treated as a untrusted module. The CrOS build\n> > > > > > system by default strips all binaries after the build step and modify\n> > > > > > the IPA .so files in so they fail the signature check.\n> > > > > >\n> > > > > > The build system inject hooks after the post_src_install hook that\n> > > > > > strips binaries and creates the packet that is installed on target. It\n> > > > > > is therefor not possible to to generate the IPA module signature for the\n> > > > > > stripped modules without also packeting the private key and doing so in\n> > > > > > pre_pkg_preinst. Stripping and generating signatures for the IPA .so\n> > > > > > files in src_install is not possible as the exact method for stripping\n> > > > > > them may differ between the ebuild and the build system hook.\n> > > > > >\n> > > > > > Safest route is to never stripp the IPA modules. Instead of restricting\n> > > > > > stripping of all libcamera binaries use dostrip to only disable\n> > > > > > stripping of the IPA modules. The EAPI needs to be increased to version\n> > > > > > 7 to support dostrip.\n> > > > >\n> > > > > Could we just disable the extra signing and signature verification on\n> > > > > Chrome OS? We have integrity enforced for the whole file system by\n> > > > > dm-verity, so there is no need to verify anything in particular\n> > > > > components of the stack anymore.\n> > > >\n> > > > The signature mechanism is how we decide if an IPA module has to be\n> > > > isolated. Once Paul's IPA IPC series gets merged, we could disable it\n> > > > indeed, which would force isolation of all IPA modules, even the\n> > > > open-source ones. Is that desired though ?\n> > > \n> > > Could you elaborate a bit more how we decide whether to isolate or not\n> > > based on this? I'd assume there would be integrators willing to run\n> > > out of tree IPAs (which could be still open source) without isolation.\n> > \n> > At the moment, we isolate all IPA modules that don't provide a valid\n> > signature. In-tree modules are signed during the build process, and are\n> > thus run without isolation (but in a separate thread, to replicate the\n> > asynchronous communication mechanism of the isolated case, in order to\n> > avoid too many differences between the two cases). Out-of-tree modules\n> > are not signed, and are thus isolated.\n> > \n> > We expect this mechanism to be extended with some or all of the\n> > following:\n> > \n> > - A flag in the module information structure to force isolated\n> > execution. This would be set, for instance, by the wrapper module for\n> > the IPU3 that loads the Intel binaries, even if the module is in-tree\n> > (we haven't decided on whether that will be the case though) and thus\n> > gets signed.\n> > \n> > - A similar mechanism that forces isolation of modules listed in a\n> > configuration file.\n> > \n> > - A method to save the private key at build time, to sign modules built\n> > out of tree. This could be used by Linux distributions to update IPA\n> > modules without having to update libcamera itself. We may also update\n> > the build process to import a public/private key pair instead of\n> > generating one.\n> \n> Quick note: Storing the generated key and signing modules at packet \n> install time is one of the possible solutions for CrOS that could be \n> added with little effort. I was reluctant to it as it feels a bit \n> redundant to ship the things that should be signed together with the \n> signing key ;-) It would however allow us to sign the IPA's after the \n> CrOS striping of the binaries at packet creation time as we could resign \n> them when they are installed on target.\n\nShipping the private key on the target would indeed make this all a bit\nuseless :-) When I mentioned saving the private key, I meant saving it\nin a secure location on the integrator's side, the same way a secureboot\nor kernel module signing key would be saved.\n\nIf there's no hook we can use post-stripping and pre-packaging, one\noption would be to strip the IPA modules manually in the src_install\nhook, resign them, and mark them with dostrip -x.\n\n> > It will ultimately be an integrator decision, as integrators will in any\n> > case have the option of carrying local modifications to libcamera that\n> > changes the IPA module loading and isolation mechanism. Changes that\n> > make sense upstream should of course be merged in our tree.\n> > \n> > Note that we also foresee changes in the isolation mechanism, at least\n> > for Chrome OS, but possibly globally, to use an algorithm daemon. I\n> > would however prefer not implementing this right now as we have more\n> > urgent tasks to focus on.\n> > \n> > > > > > Signed-off-by: Niklas Söderlund \n> > > > > > ---\n> > > > > > media-libs/libcamera/libcamera-9999.ebuild | 4 +++-\n> > > > > > 1 file changed, 3 insertions(+), 1 deletion(-)\n> > > > > >\n> > > > > > diff --git a/media-libs/libcamera/libcamera-9999.ebuild b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > > index 57ff00337309f30c..ce4183a89ef095de 100644\n> > > > > > --- a/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > > +++ b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > > @@ -1,7 +1,7 @@\n> > > > > > # Copyright 2019 The Chromium OS Authors. All rights reserved.\n> > > > > > # Distributed under the terms of the GNU General Public License v2\n> > > > > >\n> > > > > > -EAPI=6\n> > > > > > +EAPI=7\n> > > > > >\n> > > > > > CROS_WORKON_PROJECT=\"chromiumos/third_party/libcamera\"\n> > > > > > CROS_WORKON_INCREMENTAL_BUILD=\"1\"\n> > > > > > @@ -49,4 +49,6 @@ src_install() {\n> > > > > > meson_src_install\n> > > > > >\n> > > > > > dosym ../libcamera.so \"/usr/$(get_libdir)/camera_hal/libcamera.so\"\n> > > > > > +\n> > > > > > + dostrip -x /usr/$(get_libdir)/libcamera/\n> > > > > > }","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 3AB19BDB20\n\tfor ;\n\tSat, 5 Dec 2020 14:15:39 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id C12E1635F2;\n\tSat, 5 Dec 2020 15:15:38 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 39002635F0\n\tfor ;\n\tSat, 5 Dec 2020 15:15:37 +0100 (CET)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id A8850B95;\n\tSat, 5 Dec 2020 15:15:36 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"Qkm4z/1T\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1607177736;\n\tbh=UqVwN+FkiCjne3CjRBBrssXFjbIz9OOPSLM4b1FSqS0=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=Qkm4z/1TYjr71uEsy77tqiR2vCaAbRyg4hBrNOMZ/lyn20bOeVWKjdP7EwMAIaISH\n\tmnIzSxSNV3Ou6WL3DvvL5VcCybnt070Dx8iMEJYNAQ1Nd4o9IqAjWEU3DZATP8Uo9/\n\t6UMUvsZMalr35nLyxs3uYRerNyX9r8ndK5pove0s=","Date":"Sat, 5 Dec 2020 16:15:35 +0200","From":"Laurent Pinchart ","To":"Niklas =?utf-8?q?S=C3=B6derlund?= ","Message-ID":"","References":"<20201109011656.2560957-1-niklas.soderlund@ragnatech.se>\n\t<20201109011656.2560957-3-niklas.soderlund@ragnatech.se>\n\t\n\t<20201126163300.GZ3905@pendragon.ideasonboard.com>\n\t\n\t<20201204234313.GN4109@pendragon.ideasonboard.com>\n\t<20201205092019.GA2203197@oden.dyn.berto.se>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20201205092019.GA2203197@oden.dyn.berto.se>","Subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":14115,"web_url":"https://patchwork.libcamera.org/comment/14115/","msgid":"","date":"2020-12-08T02:28:20","subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","submitter":{"id":9,"url":"https://patchwork.libcamera.org/api/people/9/","name":"Tomasz Figa","email":"tfiga@chromium.org"},"content":"Hi Laurent,\n\nOn Sat, Dec 5, 2020 at 8:43 AM Laurent Pinchart\n wrote:\n>\n> Hi Tomasz,\n>\n> On Fri, Nov 27, 2020 at 01:39:40AM +0900, Tomasz Figa wrote:\n> > On Fri, Nov 27, 2020 at 1:33 AM Laurent Pinchart wrote:\n> > > On Tue, Nov 10, 2020 at 07:08:53PM +0900, Tomasz Figa wrote:\n> > > > On Mon, Nov 9, 2020 at 10:17 AM Niklas Söderlund wrote:\n> > > > >\n> > > > > Libcamera signs its IPA modules (.so files) after they are built. The\n> > > > > signature is later verified when loading the IPA modules and if they do\n> > > > > not match the IPA is treated as a untrusted module. The CrOS build\n> > > > > system by default strips all binaries after the build step and modify\n> > > > > the IPA .so files in so they fail the signature check.\n> > > > >\n> > > > > The build system inject hooks after the post_src_install hook that\n> > > > > strips binaries and creates the packet that is installed on target. It\n> > > > > is therefor not possible to to generate the IPA module signature for the\n> > > > > stripped modules without also packeting the private key and doing so in\n> > > > > pre_pkg_preinst. Stripping and generating signatures for the IPA .so\n> > > > > files in src_install is not possible as the exact method for stripping\n> > > > > them may differ between the ebuild and the build system hook.\n> > > > >\n> > > > > Safest route is to never stripp the IPA modules. Instead of restricting\n> > > > > stripping of all libcamera binaries use dostrip to only disable\n> > > > > stripping of the IPA modules. The EAPI needs to be increased to version\n> > > > > 7 to support dostrip.\n> > > >\n> > > > Could we just disable the extra signing and signature verification on\n> > > > Chrome OS? We have integrity enforced for the whole file system by\n> > > > dm-verity, so there is no need to verify anything in particular\n> > > > components of the stack anymore.\n> > >\n> > > The signature mechanism is how we decide if an IPA module has to be\n> > > isolated. Once Paul's IPA IPC series gets merged, we could disable it\n> > > indeed, which would force isolation of all IPA modules, even the\n> > > open-source ones. Is that desired though ?\n> >\n> > Could you elaborate a bit more how we decide whether to isolate or not\n> > based on this? I'd assume there would be integrators willing to run\n> > out of tree IPAs (which could be still open source) without isolation.\n>\n> At the moment, we isolate all IPA modules that don't provide a valid\n> signature. In-tree modules are signed during the build process, and are\n> thus run without isolation (but in a separate thread, to replicate the\n> asynchronous communication mechanism of the isolated case, in order to\n> avoid too many differences between the two cases). Out-of-tree modules\n> are not signed, and are thus isolated.\n>\n> We expect this mechanism to be extended with some or all of the\n> following:\n>\n> - A flag in the module information structure to force isolated\n> execution. This would be set, for instance, by the wrapper module for\n> the IPU3 that loads the Intel binaries, even if the module is in-tree\n> (we haven't decided on whether that will be the case though) and thus\n> gets signed.\n>\n> - A similar mechanism that forces isolation of modules listed in a\n> configuration file.\n>\n> - A method to save the private key at build time, to sign modules built\n> out of tree. This could be used by Linux distributions to update IPA\n> modules without having to update libcamera itself. We may also update\n> the build process to import a public/private key pair instead of\n> generating one.\n>\n> It will ultimately be an integrator decision, as integrators will in any\n> case have the option of carrying local modifications to libcamera that\n> changes the IPA module loading and isolation mechanism. Changes that\n> make sense upstream should of course be merged in our tree.\n>\n> Note that we also foresee changes in the isolation mechanism, at least\n> for Chrome OS, but possibly globally, to use an algorithm daemon. I\n> would however prefer not implementing this right now as we have more\n> urgent tasks to focus on.\n>\n\nWhile I understand this mechanism for the general purpose usage, my\npoint is that the extra signing just adds build-time complexity (and\ntime spent on the extra steps), while not serving any purpose on\nChrome OS, because we enforce the integrity and authenticity of all\nthe files with a higher level mechanism (dm-verity).\n\nCould we perhaps add a build option to just bypass that signing step\nand always enable the isolation?\n\nBest regards,\nTomasz\n\n> > > > > Signed-off-by: Niklas Söderlund \n> > > > > ---\n> > > > > media-libs/libcamera/libcamera-9999.ebuild | 4 +++-\n> > > > > 1 file changed, 3 insertions(+), 1 deletion(-)\n> > > > >\n> > > > > diff --git a/media-libs/libcamera/libcamera-9999.ebuild b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > index 57ff00337309f30c..ce4183a89ef095de 100644\n> > > > > --- a/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > +++ b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > @@ -1,7 +1,7 @@\n> > > > > # Copyright 2019 The Chromium OS Authors. All rights reserved.\n> > > > > # Distributed under the terms of the GNU General Public License v2\n> > > > >\n> > > > > -EAPI=6\n> > > > > +EAPI=7\n> > > > >\n> > > > > CROS_WORKON_PROJECT=\"chromiumos/third_party/libcamera\"\n> > > > > CROS_WORKON_INCREMENTAL_BUILD=\"1\"\n> > > > > @@ -49,4 +49,6 @@ src_install() {\n> > > > > meson_src_install\n> > > > >\n> > > > > dosym ../libcamera.so \"/usr/$(get_libdir)/camera_hal/libcamera.so\"\n> > > > > +\n> > > > > + dostrip -x /usr/$(get_libdir)/libcamera/\n> > > > > }\n>\n> --\n> Regards,\n>\n> Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id A4608BDB1F\n\tfor ;\n\tTue, 8 Dec 2020 02:28:36 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 17CBE67E6F;\n\tTue, 8 Dec 2020 03:28:36 +0100 (CET)","from mail-ej1-x643.google.com (mail-ej1-x643.google.com\n\t[IPv6:2a00:1450:4864:20::643])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 23CD567E6C\n\tfor ;\n\tTue, 8 Dec 2020 03:28:35 +0100 (CET)","by mail-ej1-x643.google.com with SMTP id jx16so22420453ejb.10\n\tfor ;\n\tMon, 07 Dec 2020 18:28:35 -0800 (PST)","from mail-wr1-f51.google.com (mail-wr1-f51.google.com.\n\t[209.85.221.51]) by smtp.gmail.com with ESMTPSA id\n\tl1sm6699344eje.12.2020.12.07.18.28.33\n\tfor \n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tMon, 07 Dec 2020 18:28:33 -0800 (PST)","by mail-wr1-f51.google.com with SMTP id k14so14727680wrn.1\n\tfor ;\n\tMon, 07 Dec 2020 18:28:33 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"de1lABWJ\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org;\n\ts=google; \n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=Htal5G7Wp1OK5s56WZIIS8/e1UnP8QWAbqxjIqV2ogY=;\n\tb=de1lABWJB2TG/ZCpKC1FjP40FiWxL1zrTdLX6zVMeuombn5tROL6ZgXw36ogDRO9oH\n\tA3nCxt7TimNGkA20oD2bd4DYlAqm/4V2uZzFDaKWhCvXXrtj0ZziTYgNOMYQoJff9VCz\n\tJeMudJe24J8iwYbLy0HrNUE0JEhLAevPxlAdI=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=Htal5G7Wp1OK5s56WZIIS8/e1UnP8QWAbqxjIqV2ogY=;\n\tb=XbLiQiDc/khb6JaEL9YJH104y7uRp6k8RHKzj4LJrbPLePusLgXQO2Ynwz3T88MGe+\n\tm3lbZp3ro3yQtL4qypQPn4GrXKKbNN8UHbkbvLfVRRKU94gEbWD3I+l4Z8oa55rdEaeH\n\tt0VRs8jNpKzv77Qkbnq5PG2/xyQJRb6+RRQFwAz4+ai3w1xv0CfSbT7CBZkWbXdIeUT9\n\tdVrIH0vcLUlcCH6bzQJ/4Oqw6Eme6K+TjdAIEi6lB/obp1YQ4nu2tzjYZXL/jxr7ObzQ\n\tQn+A3GNCT7p40wQr+F55JNEiX58OzD6QyLEnkkjUlXgSyIbc/eWxm/lPoFtFrpzPOhlV\n\tY3Jw==","X-Gm-Message-State":"AOAM532eWYuo6XdafXR7NUa0eUc2QBZzdgjIXFKXFxPEwlBl3f4esLES\n\tz0mVxiY+ycV/wJAS9T7Pzr5Nm0100JCo4w==","X-Google-Smtp-Source":"ABdhPJw3oYyhLvSjCXtHVEOM0Js9OWqAwNZ1JbbimjhdK9WnZjrpgDteaX3ocW33FcCVQBwgIaLHVg==","X-Received":["by 2002:a17:906:f153:: with SMTP id\n\tgw19mr22188972ejb.272.1607394514361; \n\tMon, 07 Dec 2020 18:28:34 -0800 (PST)","by 2002:adf:93e6:: with SMTP id\n\t93mr22640889wrp.197.1607394512675; \n\tMon, 07 Dec 2020 18:28:32 -0800 (PST)"],"MIME-Version":"1.0","References":"<20201109011656.2560957-1-niklas.soderlund@ragnatech.se>\n\t<20201109011656.2560957-3-niklas.soderlund@ragnatech.se>\n\t\n\t<20201126163300.GZ3905@pendragon.ideasonboard.com>\n\t\n\t<20201204234313.GN4109@pendragon.ideasonboard.com>","In-Reply-To":"<20201204234313.GN4109@pendragon.ideasonboard.com>","From":"Tomasz Figa ","Date":"Tue, 8 Dec 2020 11:28:20 +0900","X-Gmail-Original-Message-ID":"","Message-ID":"","To":"Laurent Pinchart ","Subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":14116,"web_url":"https://patchwork.libcamera.org/comment/14116/","msgid":"","date":"2020-12-08T02:32:31","subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Tomasz,\n\nOn Tue, Dec 08, 2020 at 11:28:20AM +0900, Tomasz Figa wrote:\n> On Sat, Dec 5, 2020 at 8:43 AM Laurent Pinchart wrote:\n> > On Fri, Nov 27, 2020 at 01:39:40AM +0900, Tomasz Figa wrote:\n> > > On Fri, Nov 27, 2020 at 1:33 AM Laurent Pinchart wrote:\n> > > > On Tue, Nov 10, 2020 at 07:08:53PM +0900, Tomasz Figa wrote:\n> > > > > On Mon, Nov 9, 2020 at 10:17 AM Niklas Söderlund wrote:\n> > > > > >\n> > > > > > Libcamera signs its IPA modules (.so files) after they are built. The\n> > > > > > signature is later verified when loading the IPA modules and if they do\n> > > > > > not match the IPA is treated as a untrusted module. The CrOS build\n> > > > > > system by default strips all binaries after the build step and modify\n> > > > > > the IPA .so files in so they fail the signature check.\n> > > > > >\n> > > > > > The build system inject hooks after the post_src_install hook that\n> > > > > > strips binaries and creates the packet that is installed on target. It\n> > > > > > is therefor not possible to to generate the IPA module signature for the\n> > > > > > stripped modules without also packeting the private key and doing so in\n> > > > > > pre_pkg_preinst. Stripping and generating signatures for the IPA .so\n> > > > > > files in src_install is not possible as the exact method for stripping\n> > > > > > them may differ between the ebuild and the build system hook.\n> > > > > >\n> > > > > > Safest route is to never stripp the IPA modules. Instead of restricting\n> > > > > > stripping of all libcamera binaries use dostrip to only disable\n> > > > > > stripping of the IPA modules. The EAPI needs to be increased to version\n> > > > > > 7 to support dostrip.\n> > > > >\n> > > > > Could we just disable the extra signing and signature verification on\n> > > > > Chrome OS? We have integrity enforced for the whole file system by\n> > > > > dm-verity, so there is no need to verify anything in particular\n> > > > > components of the stack anymore.\n> > > >\n> > > > The signature mechanism is how we decide if an IPA module has to be\n> > > > isolated. Once Paul's IPA IPC series gets merged, we could disable it\n> > > > indeed, which would force isolation of all IPA modules, even the\n> > > > open-source ones. Is that desired though ?\n> > >\n> > > Could you elaborate a bit more how we decide whether to isolate or not\n> > > based on this? I'd assume there would be integrators willing to run\n> > > out of tree IPAs (which could be still open source) without isolation.\n> >\n> > At the moment, we isolate all IPA modules that don't provide a valid\n> > signature. In-tree modules are signed during the build process, and are\n> > thus run without isolation (but in a separate thread, to replicate the\n> > asynchronous communication mechanism of the isolated case, in order to\n> > avoid too many differences between the two cases). Out-of-tree modules\n> > are not signed, and are thus isolated.\n> >\n> > We expect this mechanism to be extended with some or all of the\n> > following:\n> >\n> > - A flag in the module information structure to force isolated\n> > execution. This would be set, for instance, by the wrapper module for\n> > the IPU3 that loads the Intel binaries, even if the module is in-tree\n> > (we haven't decided on whether that will be the case though) and thus\n> > gets signed.\n> >\n> > - A similar mechanism that forces isolation of modules listed in a\n> > configuration file.\n> >\n> > - A method to save the private key at build time, to sign modules built\n> > out of tree. This could be used by Linux distributions to update IPA\n> > modules without having to update libcamera itself. We may also update\n> > the build process to import a public/private key pair instead of\n> > generating one.\n> >\n> > It will ultimately be an integrator decision, as integrators will in any\n> > case have the option of carrying local modifications to libcamera that\n> > changes the IPA module loading and isolation mechanism. Changes that\n> > make sense upstream should of course be merged in our tree.\n> >\n> > Note that we also foresee changes in the isolation mechanism, at least\n> > for Chrome OS, but possibly globally, to use an algorithm daemon. I\n> > would however prefer not implementing this right now as we have more\n> > urgent tasks to focus on.\n> >\n> \n> While I understand this mechanism for the general purpose usage, my\n> point is that the extra signing just adds build-time complexity (and\n> time spent on the extra steps), while not serving any purpose on\n> Chrome OS, because we enforce the integrity and authenticity of all\n> the files with a higher level mechanism (dm-verity).\n> \n> Could we perhaps add a build option to just bypass that signing step\n> and always enable the isolation?\n\nYes, but not yet, as the isolated code path is currently incomplete.\nPaul's work will fix that, and we expect to merge it soon, so maybe we\ncan delay this change. On the other hand, this fixes operation with IPA\nmodules right now, which is needed for development, so we all have to\ncarry this patch in our local trees. Could this be merged as a temporary\nworkaround ?\n\n> > > > > > Signed-off-by: Niklas Söderlund \n> > > > > > ---\n> > > > > > media-libs/libcamera/libcamera-9999.ebuild | 4 +++-\n> > > > > > 1 file changed, 3 insertions(+), 1 deletion(-)\n> > > > > >\n> > > > > > diff --git a/media-libs/libcamera/libcamera-9999.ebuild b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > > index 57ff00337309f30c..ce4183a89ef095de 100644\n> > > > > > --- a/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > > +++ b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > > @@ -1,7 +1,7 @@\n> > > > > > # Copyright 2019 The Chromium OS Authors. All rights reserved.\n> > > > > > # Distributed under the terms of the GNU General Public License v2\n> > > > > >\n> > > > > > -EAPI=6\n> > > > > > +EAPI=7\n> > > > > >\n> > > > > > CROS_WORKON_PROJECT=\"chromiumos/third_party/libcamera\"\n> > > > > > CROS_WORKON_INCREMENTAL_BUILD=\"1\"\n> > > > > > @@ -49,4 +49,6 @@ src_install() {\n> > > > > > meson_src_install\n> > > > > >\n> > > > > > dosym ../libcamera.so \"/usr/$(get_libdir)/camera_hal/libcamera.so\"\n> > > > > > +\n> > > > > > + dostrip -x /usr/$(get_libdir)/libcamera/\n> > > > > > }","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 50CDEBDB20\n\tfor ;\n\tTue, 8 Dec 2020 02:32:37 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id C965F67E6D;\n\tTue, 8 Dec 2020 03:32:36 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id CF84867E6C\n\tfor ;\n\tTue, 8 Dec 2020 03:32:34 +0100 (CET)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 4D1DCDD;\n\tTue, 8 Dec 2020 03:32:34 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"SUHB/M5b\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1607394754;\n\tbh=QDwCgwizt7O/MDjIUDuCN78WuOk1CEMFpZuITMl2Qp0=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=SUHB/M5bjfhbqtP7ooBXYfMEdUH2PIYYHwdQprTikgT10uqgL0phza+Ys87sBR2DX\n\ttNexVhuuXNi6NwThxMdrFEmo0O66uPKFHejoTNB6u/nJtuZSMscF4NQHLcMDY+KweH\n\tEGuW0G0zXp/PK1J34yIbnHm1I/XTJDWMTwG5JbhY=","Date":"Tue, 8 Dec 2020 04:32:31 +0200","From":"Laurent Pinchart ","To":"Tomasz Figa ","Message-ID":"","References":"<20201109011656.2560957-1-niklas.soderlund@ragnatech.se>\n\t<20201109011656.2560957-3-niklas.soderlund@ragnatech.se>\n\t\n\t<20201126163300.GZ3905@pendragon.ideasonboard.com>\n\t\n\t<20201204234313.GN4109@pendragon.ideasonboard.com>\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":14118,"web_url":"https://patchwork.libcamera.org/comment/14118/","msgid":"","date":"2020-12-08T02:40:45","subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","submitter":{"id":9,"url":"https://patchwork.libcamera.org/api/people/9/","name":"Tomasz Figa","email":"tfiga@chromium.org"},"content":"On Tue, Dec 8, 2020 at 11:32 AM Laurent Pinchart\n wrote:\n>\n> Hi Tomasz,\n>\n> On Tue, Dec 08, 2020 at 11:28:20AM +0900, Tomasz Figa wrote:\n> > On Sat, Dec 5, 2020 at 8:43 AM Laurent Pinchart wrote:\n> > > On Fri, Nov 27, 2020 at 01:39:40AM +0900, Tomasz Figa wrote:\n> > > > On Fri, Nov 27, 2020 at 1:33 AM Laurent Pinchart wrote:\n> > > > > On Tue, Nov 10, 2020 at 07:08:53PM +0900, Tomasz Figa wrote:\n> > > > > > On Mon, Nov 9, 2020 at 10:17 AM Niklas Söderlund wrote:\n> > > > > > >\n> > > > > > > Libcamera signs its IPA modules (.so files) after they are built. The\n> > > > > > > signature is later verified when loading the IPA modules and if they do\n> > > > > > > not match the IPA is treated as a untrusted module. The CrOS build\n> > > > > > > system by default strips all binaries after the build step and modify\n> > > > > > > the IPA .so files in so they fail the signature check.\n> > > > > > >\n> > > > > > > The build system inject hooks after the post_src_install hook that\n> > > > > > > strips binaries and creates the packet that is installed on target. It\n> > > > > > > is therefor not possible to to generate the IPA module signature for the\n> > > > > > > stripped modules without also packeting the private key and doing so in\n> > > > > > > pre_pkg_preinst. Stripping and generating signatures for the IPA .so\n> > > > > > > files in src_install is not possible as the exact method for stripping\n> > > > > > > them may differ between the ebuild and the build system hook.\n> > > > > > >\n> > > > > > > Safest route is to never stripp the IPA modules. Instead of restricting\n> > > > > > > stripping of all libcamera binaries use dostrip to only disable\n> > > > > > > stripping of the IPA modules. The EAPI needs to be increased to version\n> > > > > > > 7 to support dostrip.\n> > > > > >\n> > > > > > Could we just disable the extra signing and signature verification on\n> > > > > > Chrome OS? We have integrity enforced for the whole file system by\n> > > > > > dm-verity, so there is no need to verify anything in particular\n> > > > > > components of the stack anymore.\n> > > > >\n> > > > > The signature mechanism is how we decide if an IPA module has to be\n> > > > > isolated. Once Paul's IPA IPC series gets merged, we could disable it\n> > > > > indeed, which would force isolation of all IPA modules, even the\n> > > > > open-source ones. Is that desired though ?\n> > > >\n> > > > Could you elaborate a bit more how we decide whether to isolate or not\n> > > > based on this? I'd assume there would be integrators willing to run\n> > > > out of tree IPAs (which could be still open source) without isolation.\n> > >\n> > > At the moment, we isolate all IPA modules that don't provide a valid\n> > > signature. In-tree modules are signed during the build process, and are\n> > > thus run without isolation (but in a separate thread, to replicate the\n> > > asynchronous communication mechanism of the isolated case, in order to\n> > > avoid too many differences between the two cases). Out-of-tree modules\n> > > are not signed, and are thus isolated.\n> > >\n> > > We expect this mechanism to be extended with some or all of the\n> > > following:\n> > >\n> > > - A flag in the module information structure to force isolated\n> > > execution. This would be set, for instance, by the wrapper module for\n> > > the IPU3 that loads the Intel binaries, even if the module is in-tree\n> > > (we haven't decided on whether that will be the case though) and thus\n> > > gets signed.\n> > >\n> > > - A similar mechanism that forces isolation of modules listed in a\n> > > configuration file.\n> > >\n> > > - A method to save the private key at build time, to sign modules built\n> > > out of tree. This could be used by Linux distributions to update IPA\n> > > modules without having to update libcamera itself. We may also update\n> > > the build process to import a public/private key pair instead of\n> > > generating one.\n> > >\n> > > It will ultimately be an integrator decision, as integrators will in any\n> > > case have the option of carrying local modifications to libcamera that\n> > > changes the IPA module loading and isolation mechanism. Changes that\n> > > make sense upstream should of course be merged in our tree.\n> > >\n> > > Note that we also foresee changes in the isolation mechanism, at least\n> > > for Chrome OS, but possibly globally, to use an algorithm daemon. I\n> > > would however prefer not implementing this right now as we have more\n> > > urgent tasks to focus on.\n> > >\n> >\n> > While I understand this mechanism for the general purpose usage, my\n> > point is that the extra signing just adds build-time complexity (and\n> > time spent on the extra steps), while not serving any purpose on\n> > Chrome OS, because we enforce the integrity and authenticity of all\n> > the files with a higher level mechanism (dm-verity).\n> >\n> > Could we perhaps add a build option to just bypass that signing step\n> > and always enable the isolation?\n>\n> Yes, but not yet, as the isolated code path is currently incomplete.\n> Paul's work will fix that, and we expect to merge it soon, so maybe we\n> can delay this change. On the other hand, this fixes operation with IPA\n> modules right now, which is needed for development, so we all have to\n> carry this patch in our local trees. Could this be merged as a temporary\n> workaround ?\n>\n\nI'm perfectly fine with this as a temporary workaround. Let's file a\nbug to track the implementation of the bypass and have a TODO comment\nadded in the workaround, so that we don't forget about it.\n\n> > > > > > > Signed-off-by: Niklas Söderlund \n> > > > > > > ---\n> > > > > > > media-libs/libcamera/libcamera-9999.ebuild | 4 +++-\n> > > > > > > 1 file changed, 3 insertions(+), 1 deletion(-)\n> > > > > > >\n> > > > > > > diff --git a/media-libs/libcamera/libcamera-9999.ebuild b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > > > index 57ff00337309f30c..ce4183a89ef095de 100644\n> > > > > > > --- a/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > > > +++ b/media-libs/libcamera/libcamera-9999.ebuild\n> > > > > > > @@ -1,7 +1,7 @@\n> > > > > > > # Copyright 2019 The Chromium OS Authors. All rights reserved.\n> > > > > > > # Distributed under the terms of the GNU General Public License v2\n> > > > > > >\n> > > > > > > -EAPI=6\n> > > > > > > +EAPI=7\n> > > > > > >\n> > > > > > > CROS_WORKON_PROJECT=\"chromiumos/third_party/libcamera\"\n> > > > > > > CROS_WORKON_INCREMENTAL_BUILD=\"1\"\n> > > > > > > @@ -49,4 +49,6 @@ src_install() {\n> > > > > > > meson_src_install\n> > > > > > >\n> > > > > > > dosym ../libcamera.so \"/usr/$(get_libdir)/camera_hal/libcamera.so\"\n> > > > > > > +\n> > > > > > > + dostrip -x /usr/$(get_libdir)/libcamera/\n> > > > > > > }\n>\n> --\n> Regards,\n>\n> Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id C95FDBDB1F\n\tfor ;\n\tTue, 8 Dec 2020 02:41:01 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 4ECC367E6D;\n\tTue, 8 Dec 2020 03:41:01 +0100 (CET)","from mail-ed1-x542.google.com (mail-ed1-x542.google.com\n\t[IPv6:2a00:1450:4864:20::542])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 8838367E6C\n\tfor ;\n\tTue, 8 Dec 2020 03:40:59 +0100 (CET)","by mail-ed1-x542.google.com with SMTP id cw27so15994076edb.5\n\tfor ;\n\tMon, 07 Dec 2020 18:40:59 -0800 (PST)","from mail-wm1-f49.google.com (mail-wm1-f49.google.com.\n\t[209.85.128.49]) by smtp.gmail.com with ESMTPSA id\n\th23sm13945860ejg.37.2020.12.07.18.40.57\n\tfor \n\t(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n\tMon, 07 Dec 2020 18:40:58 -0800 (PST)","by mail-wm1-f49.google.com with SMTP id 3so1026975wmg.4\n\tfor ;\n\tMon, 07 Dec 2020 18:40:57 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"XhVkxEJU\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org;\n\ts=google; \n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=N0u6uMYzC3pUsGYSThQoo451iYV1ZknyledV6LZlnsg=;\n\tb=XhVkxEJUoDn2V1YBQmrpvBkP7Wz6lZtOY28ieiTH5sUbynfpwVpe4VqSbXmYB4MaGS\n\teNq5EwA5ykT2wSJ3rEy9WsAoEMthqCHRYV/0toFEz8MbMSOGUk4REy7VLYHf7ocQZIJm\n\t7zRJx4A/w3hCtlo6TBUkYnebDP4XtqFGUt4qc=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=N0u6uMYzC3pUsGYSThQoo451iYV1ZknyledV6LZlnsg=;\n\tb=YziAAR1+ihntlcrNJ23JfpczWItPo3dL0xkJWK9GodLhCLhQzlERjXP6AmQS8VnyWd\n\tVDtrEfYLeKNB5hDu+Ui/8QhYFToBPA/K9dUjSNLMI520bsbl5WCEo2O5YuI9wnlFohhX\n\tr/gI3/yo0klTTIheva6pv18Y/SrXtIPIeqPEcTh+9ICmjsSb2Aj6ccn1au5h8oDdsrO7\n\tAaHlt9lQHBwX9JDdKSZTy83ravupbRJzG0E3pD3sCiBf/P2BwzH4sRdCpN8VgD791YI4\n\tSBv7uZ8hww6XvJiHnL1W+m4VE7uPo8flKPAbsJmiTPoAUXFu1ih3qpCwbMKfywmK79Dz\n\t17CA==","X-Gm-Message-State":"AOAM5331uR0FXqNLKtJj79ePseueO7sLpPqp72XlGR038L9i5WO5oPcS\n\txm2O81nYAFQSBBb2zzAvUpvT29qBKIhfgw==","X-Google-Smtp-Source":"ABdhPJw45o4QZTkFQcLxEgH+GW2SPxpJZKhjGhSGglBy8e05iP4UVXAahlf/po5fQM81E6rq/6fp0w==","X-Received":["by 2002:a05:6402:1c90:: with SMTP id\n\tcy16mr23008032edb.73.1607395258853; \n\tMon, 07 Dec 2020 18:40:58 -0800 (PST)","by 2002:a1c:c308:: with SMTP id t8mr1691422wmf.22.1607395257403; \n\tMon, 07 Dec 2020 18:40:57 -0800 (PST)"],"MIME-Version":"1.0","References":"<20201109011656.2560957-1-niklas.soderlund@ragnatech.se>\n\t<20201109011656.2560957-3-niklas.soderlund@ragnatech.se>\n\t\n\t<20201126163300.GZ3905@pendragon.ideasonboard.com>\n\t\n\t<20201204234313.GN4109@pendragon.ideasonboard.com>\n\t\n\t","In-Reply-To":"","From":"Tomasz Figa ","Date":"Tue, 8 Dec 2020 11:40:45 +0900","X-Gmail-Original-Message-ID":"","Message-ID":"","To":"Laurent Pinchart ","Subject":"Re: [libcamera-devel] [PATCH 2/2] media-libs/libcamera: Do not\n\tstrip IPA binaries","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]