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, 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 AD2EFC07E9B for ; Tue, 20 Jul 2021 08:02:35 +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 8BC4C6023B for ; Tue, 20 Jul 2021 08:02:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8BC4C6023B 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-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1m5khg-00034h-Tu; Tue, 20 Jul 2021 04:02:12 -0400 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1m5khc-00034b-PI for kernelnewbies@kernelnewbies.org; Tue, 20 Jul 2021 04:02:08 -0400 Received: by mail-ej1-x634.google.com with SMTP id c17so32948643ejk.13 for ; Tue, 20 Jul 2021 01:02:08 -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=2edD4ZbIoOM5dgV01Aj0vA4z3mEuf8snofuXl1oXreo=; b=d95LEuqAdqoJ9ACA/94Go38gEhST2eZd9Qx7/4ma9tR1Saj3T7L/Y+GORjnWGEU2Sc 6YdawSAlWqwyZ/nn/11TgzaXx+BGOkrn6/HgBuqjebbxfyRnv1j0dVnGA1npVHdvkLT+ s2ZmXIh5mUvzoygiu+4tjVL8u3Bzy8HPhS1eL4I0Msh0Y9vuUoso1Y3m73iRSX7F5ids 8I8hukdpPLqX98oT7NZ6zuS5Mz8cAO9D8WvR4w8m2xt9aH2T/mxHeHaDhvZ3suOTOuLB 6cRgdBqQsqlCriqA73Sf7YzK6Ayx/kejohpedHFCUyaAHRJz26BTM7mRFWR+h4izZ0I3 O5pQ== 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=2edD4ZbIoOM5dgV01Aj0vA4z3mEuf8snofuXl1oXreo=; b=EizclKiXtfPilVcdEZyA2pS5g1ylEnGg+mDs0WbIWLM3EAtmldr2HhhY1S2o1YSGYe RKc98ZXHEzv0sy1qOeLrVtmeLewcieD/XIyhUYYLWgubsHhX6PAWEVXcIuVrNK1Oed9+ PIdTdLV9CadzCYczS1THjqD8BLOGidWAYge7CBSZDytsJcV7r3vjGlOVKGvmPITGlECL x0bCgsVVp+n7WWBfN9NBilp+zM7QUSDm+c85ztp65E6ESGzYmtVujA9V0o++Db2n5BsP b25X3ZmhZGHc8RnLXZenDiB/VrnQewBoN3tSd5CH23NuQgDkSzzw/Ehn6Sqlgof/Y9gQ xb1g== X-Gm-Message-State: AOAM533JCRC+6RBGOhZrwnMVBqr7fjiLGoRD7qIkUzTKafph5pqvMjjb 8BZ/mmc212h368c0zLsS+BpZLrD61bevDdPxpbI= X-Google-Smtp-Source: ABdhPJyO9ZvIDN2d6vogWARmI2N8r8z5KnWcZOZsKssnZq9MdMiE9SwxK57GIk2vAlTtMjpmt6tqwyPg5BbH3zAiNBs= X-Received: by 2002:a17:906:6050:: with SMTP id p16mr22033077ejj.43.1626768127286; Tue, 20 Jul 2021 01:02:07 -0700 (PDT) MIME-Version: 1.0 References: <568938486.33366.1626452816917.JavaMail.zimbra@nod.at> <1458549943.44607.1626686894648.JavaMail.zimbra@nod.at> <1556211076.48404.1626763215205.JavaMail.zimbra@nod.at> In-Reply-To: <1556211076.48404.1626763215205.JavaMail.zimbra@nod.at> From: Pintu Agarwal Date: Tue, 20 Jul 2021 13:31:55 +0530 Message-ID: Subject: Re: MTD: How to get actual image size from MTD partition To: Richard Weinberger Cc: Kernelnewbies , Greg KH , linux-kernel , linux-mtd , Sean Nyekjaer , linux-fsdevel , Phillip Lougher 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 On Tue, 20 Jul 2021 at 12:10, Richard Weinberger wrote: > > Anyways, I will create a separate thread for dm-verity issue and keep > > this thread still open for UBI image size issue. > > We may use dm-verify for rootfs during booting, but still we need to > > perform integrity check for other nand partitions and UBI volumes. > > > > So, instead of calculating the checksum for the entire partition, is > > it possible to perform checksum only based on the image size ? > > Right now, we are still exploring what are the best possible > > mechanisms available for this. > > I still don't fully understand what you are trying to achieve. > Is it about cryptographic integrity of your storage or detecting > errors after the flashing process? > Yes, it is about md5 checksum verification for every partition to check its integrity before updates. > But let me advertise ubiblock a second time. Sorry, I could not understand about the ubiblock request. Is it possible to elaborate little more ? We are already using squashfs on top of our UBI volumes (including rootfs mounting). This is the kernel command line we pass: rootfstype=squashfs root=/dev/mtdblock44 ubi.mtd=40,0,30 And CONFIG_MTD_UBI_BLOCK=y is already enabled in our kernel. Do we need to do something different for ubiblock ? > If you place your squashfs on a UBI static volume, UBI knows the exact length and you can checksum it > more easily. Yes, we use squashfs on UBI volumes, but our volume type is still dynamic. Also, you said, UBI knows the exact length, you mean the whole image length ? How can we get this length at runtime ? Also, how can we get the checksum of the entire UBI volume content (ignoring the erased/empty/bad block content) ? Or, you mean to say, the whole checksum logic is in-built inside the UBI layer and users don't need to worry about the integrity at all ? Thanks, Pintu _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies