From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78130C4320E for ; Tue, 31 Aug 2021 13:19:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5FE9960F46 for ; Tue, 31 Aug 2021 13:19:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235284AbhHaNUj (ORCPT ); Tue, 31 Aug 2021 09:20:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233928AbhHaNUh (ORCPT ); Tue, 31 Aug 2021 09:20:37 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 492F4C061575; Tue, 31 Aug 2021 06:19:42 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id n11so26709282edv.11; Tue, 31 Aug 2021 06:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sHPtKZe+G6zxzj4XJ8SxB02koJw5U2FZ5BVM7LmQV+E=; b=mPKAMH17uL9S9ww1ldPDQOsQ4tTR+P+D3eOikgUSj0/+DitNDCohbo4ATcp1I06SjT DtASqynYghW0q1tPUeMWGawXlf0BFDZDe9W9LfZoTUBzaDmO+SsnKPGwswyHM9cysBWv 4dXshjYaPHsm5wiPS8yv5btgABt9VfHyhyTQ0pp27r3RtOEUJG4mOx9Aof4boWcpriPC WmAO0yAdJJ5bXh6Qcze45IPs8ymDvoyTzQWwgJe8uW2f+g+Bs5RC8aaPz2P0RFuUseWe b0waCZ9QlHqyvpigVnykIqxtucM9IwJpoIX/QBCE/8MkozyCsuo0YzXplg2GcSTjZIms JKJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sHPtKZe+G6zxzj4XJ8SxB02koJw5U2FZ5BVM7LmQV+E=; b=T7k9xP6Gc7Rm+0wj3D5H+yy/XVcKGuHM55fkYKJLQE0M1+J5R+tcWmVzRB2j4jVZUe PYjzqBJNf6PZJ+GbUG0QJTkmOR4zKPQDz5MlHii4YzRHCtW+rgKk/haV1QN6FRvmM/AL wMklMR9DDVuvmCKHO0GN1iVHrHrsF3T8V6QXbv+L34nQS1CHGpwJgNewpcT1AtPxUMeQ Z9pGaI8nmclNw1l3O7dyyrXEH9ax7AG7Pq4wAsboXdiVMOB/OPQk3VCYCKVLKQNhmq/a csBV9JL9xf2JcUGwHvjwLTEL28TSw6ZhB6ZFY0i1kmOuTG/lwSVAdMzkSeFQ4GjCKEt1 46Gw== X-Gm-Message-State: AOAM533s5b1khuES0pyzplUwOdb4/FPvQrhoMy4PtynZ7oKE6cejP226 n6O+xcbMAtSrT2Tg48JP7ijdo2YXOzAY+7g8Nh4= X-Google-Smtp-Source: ABdhPJwT+pZxjrRI5pwhP4OcAeoy4nNGBgvF439fo+caHd7TPPXqp99zWOeMMGPaHPRArVb7drlTb+9fGGonvNasmbw= X-Received: by 2002:a05:6402:5107:: with SMTP id m7mr29849642edd.63.1630415980838; Tue, 31 Aug 2021 06:19:40 -0700 (PDT) MIME-Version: 1.0 References: <20210830185541.715f6a39@windsurf> <20210830211224.76391708@windsurf> In-Reply-To: <20210830211224.76391708@windsurf> From: Pintu Agarwal Date: Tue, 31 Aug 2021 18:49:28 +0530 Message-ID: Subject: Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue To: Thomas Petazzoni Cc: Mikulas Patocka , open list , Phillip Lougher , linux-fsdevel , linux-mtd , dm-devel@redhat.com, Kernelnewbies , agk@redhat.com, snitzer@redhat.com, Sami Tolvanen Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, 31 Aug 2021 at 00:42, Thomas Petazzoni wrote: > > Hello, > > On Mon, 30 Aug 2021 23:48:40 +0530 > Pintu Agarwal wrote: > > > ohh that means we already have a working reference. > > If possible can you share the details, even 4.19 or higher will be > > also a good reference. > > > > > > Or, another option is to use the new concept from 5.1 kernel that is: > > > > dm-mod.create = ? > > > How are you doing it today without dm-mod.create ? > > I think in 4.14 we don't have dm-mod.create right ? > > No, but you can backport it easily. Back at > http://lists.infradead.org/pipermail/openwrt-devel/2019-November/025967.html > I provided backports of this feature to OpenWrt, for the 4.14 and 4.19 > kernels. > Yes, I can backport it to our 4.14 Kernel. Can you share the list of patches to be backported to make it work on 4.14 ? If it's backported also I need to report to our internal kernel, but it might be slightly easier. Please share the details. > > Here is our kernel command line: > > > > [ 0.000000] Kernel command line: ro rootwait > > console=ttyMSM0,115200,n8 .... verity="95384 11923 > > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 12026 > > " rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0 > > .... init=/sbin/init root=/dev/dm-0 dm="rootfs none ro,0 95384 verity > > 1 /dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256 > > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 > > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10 > > restart_on_corruption ignore_zero_blocks use_fec_from_device > > /dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026" ... > > I don't see how this can work without the dm-mod.create feature. Are > you sure the verity= and dm= kernel arguments exist? Sorry, I am not a security guy and this was done by someone from the security team. But, I know that this is already working with ext4. The moment we change to squashfs, it does not work. The only difference with squashfs are: => verity metadata are kept on separate volume => The rootfstype and related stuff are different => verity command line related stuff are almost the same. Also, you mentioned: >>> Here, it definitely worked to append the hash tree to the squashfs >>> image and store them in the same partition. Can you share some details about it ? How it can be done since squashfs is readonly. Do, we need to change some parameters during squashfs image generation ? { $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \ - -nopad -noappend -root-owned \ + -noappend -root-owned \ } Also, for the above cmdline, is there any problem with the block size ? As @Mikulas said before that the block size could be the issue Also, for squashfs we are passing like this for root=. Is it fine ? rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0 I see that dm-0 is already passed elsewhere so do we really need it ? I suspect it is not required as a block device. Thanks, Pintu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F493C432BE for ; Tue, 31 Aug 2021 13:20:24 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BF0E760F46 for ; Tue, 31 Aug 2021 13:20:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BF0E760F46 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1mL3g2-0003lx-45; Tue, 31 Aug 2021 09:19:46 -0400 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1mL3fz-0003lK-FY for kernelnewbies@kernelnewbies.org; Tue, 31 Aug 2021 09:19:43 -0400 Received: by mail-ed1-x533.google.com with SMTP id s25so26863642edw.0 for ; Tue, 31 Aug 2021 06:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sHPtKZe+G6zxzj4XJ8SxB02koJw5U2FZ5BVM7LmQV+E=; b=mPKAMH17uL9S9ww1ldPDQOsQ4tTR+P+D3eOikgUSj0/+DitNDCohbo4ATcp1I06SjT DtASqynYghW0q1tPUeMWGawXlf0BFDZDe9W9LfZoTUBzaDmO+SsnKPGwswyHM9cysBWv 4dXshjYaPHsm5wiPS8yv5btgABt9VfHyhyTQ0pp27r3RtOEUJG4mOx9Aof4boWcpriPC WmAO0yAdJJ5bXh6Qcze45IPs8ymDvoyTzQWwgJe8uW2f+g+Bs5RC8aaPz2P0RFuUseWe b0waCZ9QlHqyvpigVnykIqxtucM9IwJpoIX/QBCE/8MkozyCsuo0YzXplg2GcSTjZIms JKJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sHPtKZe+G6zxzj4XJ8SxB02koJw5U2FZ5BVM7LmQV+E=; b=EyMpdzlf2Tn0AQ7xOLbc0vywrpQD1eYldsugwcNGIJToW2pRk3gnih6FS3sPC8aFbN TOcc/jnvMfQBcrjWk4okUwlMK4cxssij/VgVIh0IHlE5JtNFQnMgwHHu1hLsgti8UegJ HCT4LxIAhLuzzOwCtt+Qx+F3+BjexChX7w7tmkSvyosxLwu+LjEElGqAoR14qLiWFibx exbSUpCv1OeFM44M9pPhPMegbDE/TX1Vy5japFwtQ7OhFaiHEMqUu1WQZAypT9zqlvd8 lL3SGkXqOUvoTUOyILjEtLqPR0IdnrEt9gGivMyypHRNpsp2F1bMhKMte0i+O33GTR0h XHnQ== X-Gm-Message-State: AOAM532RtFSpm0Ihlqa1mKJoUr7cf0yT5/mRSxQ3WlBmc6hjWSWgNHkR vprPAEUWJ6ZT0383VO927IYBnVtdFV5/DExXI40= X-Google-Smtp-Source: ABdhPJwT+pZxjrRI5pwhP4OcAeoy4nNGBgvF439fo+caHd7TPPXqp99zWOeMMGPaHPRArVb7drlTb+9fGGonvNasmbw= X-Received: by 2002:a05:6402:5107:: with SMTP id m7mr29849642edd.63.1630415980838; Tue, 31 Aug 2021 06:19:40 -0700 (PDT) MIME-Version: 1.0 References: <20210830185541.715f6a39@windsurf> <20210830211224.76391708@windsurf> In-Reply-To: <20210830211224.76391708@windsurf> From: Pintu Agarwal Date: Tue, 31 Aug 2021 18:49:28 +0530 Message-ID: Subject: Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue To: Thomas Petazzoni Cc: Sami Tolvanen , snitzer@redhat.com, Kernelnewbies , open list , dm-devel@redhat.com, Mikulas Patocka , linux-mtd , linux-fsdevel , Phillip Lougher , agk@redhat.com X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org Hi, On Tue, 31 Aug 2021 at 00:42, Thomas Petazzoni wrote: > > Hello, > > On Mon, 30 Aug 2021 23:48:40 +0530 > Pintu Agarwal wrote: > > > ohh that means we already have a working reference. > > If possible can you share the details, even 4.19 or higher will be > > also a good reference. > > > > > > Or, another option is to use the new concept from 5.1 kernel that is: > > > > dm-mod.create = ? > > > How are you doing it today without dm-mod.create ? > > I think in 4.14 we don't have dm-mod.create right ? > > No, but you can backport it easily. Back at > http://lists.infradead.org/pipermail/openwrt-devel/2019-November/025967.html > I provided backports of this feature to OpenWrt, for the 4.14 and 4.19 > kernels. > Yes, I can backport it to our 4.14 Kernel. Can you share the list of patches to be backported to make it work on 4.14 ? If it's backported also I need to report to our internal kernel, but it might be slightly easier. Please share the details. > > Here is our kernel command line: > > > > [ 0.000000] Kernel command line: ro rootwait > > console=ttyMSM0,115200,n8 .... verity="95384 11923 > > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 12026 > > " rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0 > > .... init=/sbin/init root=/dev/dm-0 dm="rootfs none ro,0 95384 verity > > 1 /dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256 > > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 > > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10 > > restart_on_corruption ignore_zero_blocks use_fec_from_device > > /dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026" ... > > I don't see how this can work without the dm-mod.create feature. Are > you sure the verity= and dm= kernel arguments exist? Sorry, I am not a security guy and this was done by someone from the security team. But, I know that this is already working with ext4. The moment we change to squashfs, it does not work. The only difference with squashfs are: => verity metadata are kept on separate volume => The rootfstype and related stuff are different => verity command line related stuff are almost the same. Also, you mentioned: >>> Here, it definitely worked to append the hash tree to the squashfs >>> image and store them in the same partition. Can you share some details about it ? How it can be done since squashfs is readonly. Do, we need to change some parameters during squashfs image generation ? { $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \ - -nopad -noappend -root-owned \ + -noappend -root-owned \ } Also, for the above cmdline, is there any problem with the block size ? As @Mikulas said before that the block size could be the issue Also, for squashfs we are passing like this for root=. Is it fine ? rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0 I see that dm-0 is already passed elsewhere so do we really need it ? I suspect it is not required as a block device. Thanks, Pintu _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 539D3C432BE for ; Tue, 31 Aug 2021 13:20:44 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0863E60F46 for ; Tue, 31 Aug 2021 13:20:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0863E60F46 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qk96LUPkj9cbOEZjbuNt9F2O/ErR5hHWCLSThMany9Q=; b=vp8blG0dlqkCcN qSVzUrOnCqnWewWHpWB2p/UKIUg5+xJjgb4hxcRR6xsxISwpYcsv2idnURqhVn1Df+pdz8HY4ldZQ WOn0FIuqSXovZ8ehzMfxx4wLhkhabco4QYTlap0xke749ulPdHLRmJuZT3/qOQAzQZmmQr/66Uqj8 HFIWpNOEQ43bpkaOkvC/8o55OR3oIvA9V9RBUh1ubEnozSD9gzrjKoy/mhKoPuG/5+T+3ponlAB/1 ujpjUcyAJoMSJi+y/nv661NFwd3HvwmvsVkjwHd22Zdsd/LUqSsiHqXjpzz4EuWtl9OsqK29kGZsY 5QSv8CYY/MyWEfnGNiVQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mL3g3-002J9E-S9; Tue, 31 Aug 2021 13:19:47 +0000 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mL3fy-002J7V-Kx for linux-mtd@lists.infradead.org; Tue, 31 Aug 2021 13:19:46 +0000 Received: by mail-ed1-x534.google.com with SMTP id dm15so26754445edb.10 for ; Tue, 31 Aug 2021 06:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sHPtKZe+G6zxzj4XJ8SxB02koJw5U2FZ5BVM7LmQV+E=; b=mPKAMH17uL9S9ww1ldPDQOsQ4tTR+P+D3eOikgUSj0/+DitNDCohbo4ATcp1I06SjT DtASqynYghW0q1tPUeMWGawXlf0BFDZDe9W9LfZoTUBzaDmO+SsnKPGwswyHM9cysBWv 4dXshjYaPHsm5wiPS8yv5btgABt9VfHyhyTQ0pp27r3RtOEUJG4mOx9Aof4boWcpriPC WmAO0yAdJJ5bXh6Qcze45IPs8ymDvoyTzQWwgJe8uW2f+g+Bs5RC8aaPz2P0RFuUseWe b0waCZ9QlHqyvpigVnykIqxtucM9IwJpoIX/QBCE/8MkozyCsuo0YzXplg2GcSTjZIms JKJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sHPtKZe+G6zxzj4XJ8SxB02koJw5U2FZ5BVM7LmQV+E=; b=bG0JjoMh1XJTOB2s4SIvVzeCBvrUJge19C7GuQyQ8AtKBKF/muOJFbCzKzuDJOgVbv xhiiFVA+wem7j+Hfs0PLsc/pzmkr5y1nCdRZWCsjRie4u1wn9ip8uKCePQVVMszeB1kU gwO4j1QbjcUqTAea46I+cPHGlpnNPR1HKmXPFZE5in9DBJzao3burnmaMoMoCL6Ddf8l ek8635s8iTdcxi2+K8FTanreKq6L2f5Yi07MUDW2MsiSwJu86xKySrBJh34TT0Ky1chz gX8AeVJXrpQP4vSOVwO10NCkz+pQawMOucwY3KBfmnZPRYtn78R3u5/OLp/TAaNUDnmt VMCg== X-Gm-Message-State: AOAM531T/cpVZGNYmuX5JxxOnHYSRk1SfCDMuyadMDWBY55oiGXhwiQd jPCRRLSiuHe3rKcg/j6yZlJzQCeMG5+uIWWMgjw= X-Google-Smtp-Source: ABdhPJwT+pZxjrRI5pwhP4OcAeoy4nNGBgvF439fo+caHd7TPPXqp99zWOeMMGPaHPRArVb7drlTb+9fGGonvNasmbw= X-Received: by 2002:a05:6402:5107:: with SMTP id m7mr29849642edd.63.1630415980838; Tue, 31 Aug 2021 06:19:40 -0700 (PDT) MIME-Version: 1.0 References: <20210830185541.715f6a39@windsurf> <20210830211224.76391708@windsurf> In-Reply-To: <20210830211224.76391708@windsurf> From: Pintu Agarwal Date: Tue, 31 Aug 2021 18:49:28 +0530 Message-ID: Subject: Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue To: Thomas Petazzoni Cc: Mikulas Patocka , open list , Phillip Lougher , linux-fsdevel , linux-mtd , dm-devel@redhat.com, Kernelnewbies , agk@redhat.com, snitzer@redhat.com, Sami Tolvanen X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210831_061942_751082_80AD4389 X-CRM114-Status: GOOD ( 26.56 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org Hi, On Tue, 31 Aug 2021 at 00:42, Thomas Petazzoni wrote: > > Hello, > > On Mon, 30 Aug 2021 23:48:40 +0530 > Pintu Agarwal wrote: > > > ohh that means we already have a working reference. > > If possible can you share the details, even 4.19 or higher will be > > also a good reference. > > > > > > Or, another option is to use the new concept from 5.1 kernel that is: > > > > dm-mod.create = ? > > > How are you doing it today without dm-mod.create ? > > I think in 4.14 we don't have dm-mod.create right ? > > No, but you can backport it easily. Back at > http://lists.infradead.org/pipermail/openwrt-devel/2019-November/025967.html > I provided backports of this feature to OpenWrt, for the 4.14 and 4.19 > kernels. > Yes, I can backport it to our 4.14 Kernel. Can you share the list of patches to be backported to make it work on 4.14 ? If it's backported also I need to report to our internal kernel, but it might be slightly easier. Please share the details. > > Here is our kernel command line: > > > > [ 0.000000] Kernel command line: ro rootwait > > console=ttyMSM0,115200,n8 .... verity="95384 11923 > > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 12026 > > " rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0 > > .... init=/sbin/init root=/dev/dm-0 dm="rootfs none ro,0 95384 verity > > 1 /dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256 > > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 > > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10 > > restart_on_corruption ignore_zero_blocks use_fec_from_device > > /dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026" ... > > I don't see how this can work without the dm-mod.create feature. Are > you sure the verity= and dm= kernel arguments exist? Sorry, I am not a security guy and this was done by someone from the security team. But, I know that this is already working with ext4. The moment we change to squashfs, it does not work. The only difference with squashfs are: => verity metadata are kept on separate volume => The rootfstype and related stuff are different => verity command line related stuff are almost the same. Also, you mentioned: >>> Here, it definitely worked to append the hash tree to the squashfs >>> image and store them in the same partition. Can you share some details about it ? How it can be done since squashfs is readonly. Do, we need to change some parameters during squashfs image generation ? { $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \ - -nopad -noappend -root-owned \ + -noappend -root-owned \ } Also, for the above cmdline, is there any problem with the block size ? As @Mikulas said before that the block size could be the issue Also, for squashfs we are passing like this for root=. Is it fine ? rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0 I see that dm-0 is already passed elsewhere so do we really need it ? I suspect it is not required as a block device. Thanks, Pintu ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E57F6C432BE for ; Wed, 1 Sep 2021 06:59:15 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7165761074 for ; Wed, 1 Sep 2021 06:59:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7165761074 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-461--Xu-MwQzNY2nUPUk1eSz_Q-1; Wed, 01 Sep 2021 02:59:12 -0400 X-MC-Unique: -Xu-MwQzNY2nUPUk1eSz_Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BB475801ADA; Wed, 1 Sep 2021 06:59:07 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D4A3B5DEB8; Wed, 1 Sep 2021 06:59:06 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 08D431809C98; Wed, 1 Sep 2021 06:59:04 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 17VDJtvK006939 for ; Tue, 31 Aug 2021 09:19:55 -0400 Received: by smtp.corp.redhat.com (Postfix) id 14279214180A; Tue, 31 Aug 2021 13:19:55 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0C7A7200ACE1 for ; Tue, 31 Aug 2021 13:19:48 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D6C9418A01A5 for ; Tue, 31 Aug 2021 13:19:48 +0000 (UTC) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-150-G2HL6E8VNwqkbw0EMeZo3Q-1; Tue, 31 Aug 2021 09:19:42 -0400 X-MC-Unique: G2HL6E8VNwqkbw0EMeZo3Q-1 Received: by mail-ed1-f48.google.com with SMTP id z19so26729403edi.9; Tue, 31 Aug 2021 06:19:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sHPtKZe+G6zxzj4XJ8SxB02koJw5U2FZ5BVM7LmQV+E=; b=b+aF8C+gGguGUWUNOOjp54Oe6UiUdgcr4HoYPVJFFkSYii9HaLPiqFU9Dh7JV3dXPM nNG+kZn7QPT1KB528Y1yBFySd9eBEtz/oS+G6GEo4kYUwvS1YScUJNNA8esnF2pqtmPZ 5OzMBzsoMGnm2/0i1kCGk+IOZX8mx2irC26akNMaSwV8Cr/ZByOUDy+jIqnhhFYOrUSu kB52bCqdl6Ou4/J4M84w7b/VvY8I2BEZCCuPK6GH4ICOEMyfaraAZ4qetNzKrq9pqOTW X7CdiPQ8R1bzE8fXVDiXKsZhQrYC073dsho9CY0tcQcq3mZj7hw444vElsoGaWhHeHzw 4i4A== X-Gm-Message-State: AOAM532msjz/KzurLuAJ0XVJdibkBRhLeEXMkCKmw6yMy6f453gPnn47 M77b+j2jL70rn60ordVUm4zcFIbM1osLkkBLaMk= X-Google-Smtp-Source: ABdhPJwT+pZxjrRI5pwhP4OcAeoy4nNGBgvF439fo+caHd7TPPXqp99zWOeMMGPaHPRArVb7drlTb+9fGGonvNasmbw= X-Received: by 2002:a05:6402:5107:: with SMTP id m7mr29849642edd.63.1630415980838; Tue, 31 Aug 2021 06:19:40 -0700 (PDT) MIME-Version: 1.0 References: <20210830185541.715f6a39@windsurf> <20210830211224.76391708@windsurf> In-Reply-To: <20210830211224.76391708@windsurf> From: Pintu Agarwal Date: Tue, 31 Aug 2021 18:49:28 +0530 Message-ID: To: Thomas Petazzoni X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-loop: dm-devel@redhat.com X-Mailman-Approved-At: Wed, 01 Sep 2021 02:57:42 -0400 Cc: Sami Tolvanen , snitzer@redhat.com, Kernelnewbies , open list , dm-devel@redhat.com, Mikulas Patocka , linux-mtd , linux-fsdevel , Phillip Lougher , agk@redhat.com Subject: Re: [dm-devel] Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, On Tue, 31 Aug 2021 at 00:42, Thomas Petazzoni wrote: > > Hello, > > On Mon, 30 Aug 2021 23:48:40 +0530 > Pintu Agarwal wrote: > > > ohh that means we already have a working reference. > > If possible can you share the details, even 4.19 or higher will be > > also a good reference. > > > > > > Or, another option is to use the new concept from 5.1 kernel that is: > > > > dm-mod.create = ? > > > How are you doing it today without dm-mod.create ? > > I think in 4.14 we don't have dm-mod.create right ? > > No, but you can backport it easily. Back at > http://lists.infradead.org/pipermail/openwrt-devel/2019-November/025967.html > I provided backports of this feature to OpenWrt, for the 4.14 and 4.19 > kernels. > Yes, I can backport it to our 4.14 Kernel. Can you share the list of patches to be backported to make it work on 4.14 ? If it's backported also I need to report to our internal kernel, but it might be slightly easier. Please share the details. > > Here is our kernel command line: > > > > [ 0.000000] Kernel command line: ro rootwait > > console=ttyMSM0,115200,n8 .... verity="95384 11923 > > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 12026 > > " rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0 > > .... init=/sbin/init root=/dev/dm-0 dm="rootfs none ro,0 95384 verity > > 1 /dev/ubiblock0_0 /dev/mtdblock53 4096 4096 11923 8 sha256 > > 16da5e4bbc706e5d90511d2a3dae373b5d878f9aebd522cd614a4faaace6baa3 > > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10 > > restart_on_corruption ignore_zero_blocks use_fec_from_device > > /dev/mtdblock53 fec_roots 2 fec_blocks 12026 fec_start 12026" ... > > I don't see how this can work without the dm-mod.create feature. Are > you sure the verity= and dm= kernel arguments exist? Sorry, I am not a security guy and this was done by someone from the security team. But, I know that this is already working with ext4. The moment we change to squashfs, it does not work. The only difference with squashfs are: => verity metadata are kept on separate volume => The rootfstype and related stuff are different => verity command line related stuff are almost the same. Also, you mentioned: >>> Here, it definitely worked to append the hash tree to the squashfs >>> image and store them in the same partition. Can you share some details about it ? How it can be done since squashfs is readonly. Do, we need to change some parameters during squashfs image generation ? { $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \ - -nopad -noappend -root-owned \ + -noappend -root-owned \ } Also, for the above cmdline, is there any problem with the block size ? As @Mikulas said before that the block size could be the issue Also, for squashfs we are passing like this for root=. Is it fine ? rootfstype=squashfs ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/dm-0 I see that dm-0 is already passed elsewhere so do we really need it ? I suspect it is not required as a block device. Thanks, Pintu -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel