Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp4484166pxb; Tue, 31 Aug 2021 06:24:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz8fU0aLhxkQjpsMJprYqieLS7rBqDhoOIrEHLiaSnywLkhRlSvSUok44CL2y3vniNVMIQG X-Received: by 2002:aa7:c64d:: with SMTP id z13mr29810910edr.349.1630416259305; Tue, 31 Aug 2021 06:24:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630416259; cv=none; d=google.com; s=arc-20160816; b=I4eNYbCelNTyK0Uxzj6c6J5WxdiPfl2/frbEr4IFAFXQC6tg9JsY/RZ9zG6JTvK0Jt irlkgeAZszwRrx4QNBORGp9gbA5J02az8xPZ9LOSOXop6xpj0CG3LkjslxAvLg+ZUhdL XOuyqHGXvT7p31oTdR7h92wkz5oJC1t1uIMVFeZzbayfFp53fLAmMCrIrYvMrq7ELDgp U7v/fTfLwQMiQ8Ktq36GueB21hWXlv2WXSW8kVGSxpuIIZ3ZPJ7de3TRtT/mcV+UPNcR 83KLNOk8dAFpg520MluEqG15+e0HUTH4d305xJje4NqnPPFi13abewWecO9lF9dKSU1Z Pcvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=sHPtKZe+G6zxzj4XJ8SxB02koJw5U2FZ5BVM7LmQV+E=; b=jAezP/J5gkcLOtVq5sAVsS/wrXbz2pBmzWjVAcKmqzskRvJ6SlUgIduq4o/AZ1kWD0 7ddVRhSrfz8vhuKaQn4WMwjmqLlPtBf8KThncls7VIvqTY6IpyFPYTxf0Yg+Tpt6GYeD 2LSJvr8piFFaw7A/p3H7SCs0TOYaLKokdNnzGuBCE+bHulf8MZt5QQbWr1lzYnIpH4nm dAyxWy0fWHW5DrDx0bQxsRerPlx0t5IHuUoohjR1dqkvj88QCfuH6F03/2l1VfQDLN5a Qo1kyrvXTkfxD1Z8RVIBMhTcdsa2SNhwid8K+GK70RMabSRxaPfd2U+0gDEAUDZ0ZOmh 18Dw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mPKAMH17; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g22si16909403edr.172.2021.08.31.06.23.21; Tue, 31 Aug 2021 06:24:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mPKAMH17; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235219AbhHaNUi (ORCPT + 99 others); Tue, 31 Aug 2021 09:20:38 -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-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