Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3285594pxf; Mon, 22 Mar 2021 02:41:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyd+oRcmRYmLtyHCvvCZUNYp0mMzgCuvzWII3/sx9qSJSydoTeU7dZFmKY2aBdV17W07MNA X-Received: by 2002:a05:6402:1393:: with SMTP id b19mr24493135edv.333.1616406112073; Mon, 22 Mar 2021 02:41:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616406112; cv=none; d=google.com; s=arc-20160816; b=nc1rM5dB8aAFuOIKQMKA4OmPYUj7RqgQ6iDsS2V6EHs/GGoJ0dI/8mVrgKlO+Tlyoc 6yh9kZpC7lAmNGFlBCm0sW7MP7QWS+abLUIS/z3SWDm6q1ghUYhoTmKfzLOYsKKU2ytQ JNxgBVtc4/frEFVsNOMYDV3AgKIAzfx1N/H8h6oD5bJlhStjJ0I+138Bk1c58PPX4epm lShE8H41biyxlamV3Ae4ehJCJEANmkccvX+40EoahYfP3U9KVWSlOi9ZzysXzSUhGrGf /2QqIwDF1DmQOpALHrasDitHJZPdCAkIW8k3J5YMHX2UH7DoPAScvCBFjdLVu7ZzeWwz R0eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=wqHZMdC6rUxDyCcQ9/UiKhgX+/ervzY6iVzUm9vwHtE=; b=APDTW9kk2HB3HfwU0WoqOEvHJJ9VrA04cXHVWk0z6wFMFV6pGYi/jYMWwB/NiA+ug3 u4VJYMCTwJOQ9ANXhl4jJBUTSsNKPif2C1WxoMBBDujEzNyLajP4rEo2dDNNriVtGcst kUUftbYpe0ativME6VYUpXDz8Q0PIR158vHIJ4vPcLAbwXrlSLHlZvNkNIH2PM1zLxcr 4LEQ7lYSYI4g4x6A2lQWa18XxAZFgBStIrY6GR7unO65FaNs11dBjaLtPM9qlbNTJmEv HaZaIvwbUd7VHE4i4hCbSeLG/Cwp8EG8269FJr2qTQ/u48HQ/AJXOMV0leMlOEX5KYzV 0pvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=qIuXQout; 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=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u26si11342903ejx.30.2021.03.22.02.41.29; Mon, 22 Mar 2021 02:41:52 -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=@linaro.org header.s=google header.b=qIuXQout; 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=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230163AbhCVJj7 (ORCPT + 99 others); Mon, 22 Mar 2021 05:39:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230050AbhCVJje (ORCPT ); Mon, 22 Mar 2021 05:39:34 -0400 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F886C061762 for ; Mon, 22 Mar 2021 02:39:34 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id w8so8101167pjf.4 for ; Mon, 22 Mar 2021 02:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wqHZMdC6rUxDyCcQ9/UiKhgX+/ervzY6iVzUm9vwHtE=; b=qIuXQoutDEgBKQInI7J0pFo7lPchsNyAgwQuoNJ2wFzSsG8ykCUIZ+YPFqtoS26Mz1 hV+bXEEnX67VZq1EKNpC+7mrPcRdyeSCGU5S5GqBWysh6kfmKNA9gPwJQ1bHL+Lh06uh A2YPCKKulH2mRo2f8kBkgq+URI3KKFh/Bm4ZWJIt4eZwFDOvz2UXXHgW8FqGewIj6jP3 mv7xXEha8ltbpZ6KxJVkVWp9JOEOdaOplsK+BIX0O1t0d3xgCvSW0CH/czcR/+Q4JI40 kQuSyB69pnreP0f0a8ypQscp1vjsweLxYFDoJBjGN4WNvHua5X6klQRus5ri7IrB0UEj fzDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wqHZMdC6rUxDyCcQ9/UiKhgX+/ervzY6iVzUm9vwHtE=; b=HgCADFFmZLYyVxJTlh0Co7x1xw6GEA7Zrv+ApFnR2nsCg/136WYisg80QWiu7Wvr8W FX1urhUpxfHFcQT+4PLTk6iTkMCZ+ouAhLIWHS7HzONy5IfAK9jtXRo9zqPBEMfPxpDL S7s5q/D3YlQdRvrmQr4QMaps/0fKsiLI6+Ag022K9dX8Xt92QKEP/c9ggAfMUol8kABU uno/iB4yLEIAhsHi6qg+3leWUjKLo7rPdn8EYY2FAJKGLA2Hw1AGn4niPg3Lv1t3l7gY 7UIhFkpduOPFEu1VRXuB6h/hUvN7aVhre5G97XkTBDN5f4KIPOkzSbJjFtHvdW+vqelZ XiDw== X-Gm-Message-State: AOAM532jnac4k6ZHWxW0mdFTJG0m4ymJZ5Ib8O4FkTRHXXONz9dkrrhO xkamoCIl9ylC0bAkjRbG2ugx X-Received: by 2002:a17:90a:d3d1:: with SMTP id d17mr12193992pjw.21.1616405974041; Mon, 22 Mar 2021 02:39:34 -0700 (PDT) Received: from thinkpad ([2409:4072:88e:ef5e:dccf:398f:4151:2e02]) by smtp.gmail.com with ESMTPSA id j188sm13320925pfd.64.2021.03.22.02.39.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Mar 2021 02:39:33 -0700 (PDT) Date: Mon, 22 Mar 2021 15:09:23 +0530 From: Manivannan Sadhasivam To: Boris Brezillon Cc: miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com, robh+dt@kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Daniele.Palmas@telit.com, bjorn.andersson@linaro.org Subject: Re: [PATCH v7 3/3] mtd: rawnand: Add support for secure regions in NAND memory Message-ID: <20210322093923.GA70634@thinkpad> References: <20210319150010.32122-1-manivannan.sadhasivam@linaro.org> <20210319150010.32122-4-manivannan.sadhasivam@linaro.org> <20210319175258.2cce6acd@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210319175258.2cce6acd@collabora.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 19, 2021 at 05:52:58PM +0100, Boris Brezillon wrote: > On Fri, 19 Mar 2021 20:30:10 +0530 > Manivannan Sadhasivam wrote: > > > On a typical end product, a vendor may choose to secure some regions in > > the NAND memory which are supposed to stay intact between FW upgrades. > > The access to those regions will be blocked by a secure element like > > Trustzone. So the normal world software like Linux kernel should not > > touch these regions (including reading). > > > > The regions are declared using a NAND chip DT property, > > "secure-regions". So let's make use of this property in the raw NAND > > core and skip access to the secure regions present in a system. > > > > Signed-off-by: Manivannan Sadhasivam > > --- > > drivers/mtd/nand/raw/nand_base.c | 111 +++++++++++++++++++++++++++++++ > > include/linux/mtd/rawnand.h | 4 ++ > > 2 files changed, 115 insertions(+) > > > > diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c > > index c33fa1b1847f..479a79e682cd 100644 > > --- a/drivers/mtd/nand/raw/nand_base.c > > +++ b/drivers/mtd/nand/raw/nand_base.c > > @@ -278,11 +278,47 @@ static int nand_block_bad(struct nand_chip *chip, loff_t ofs) > > return 0; > > } > > > > +/** > > + * nand_check_secure_region() - Check if the region is secured > > + * @chip: NAND chip object > > + * @offset: Offset of the region to check > > + * @size: Size of the region to check > > + * > > + * Checks if the region is secured by comparing the offset and size with the > > + * list of secure regions obtained from DT. Returns -EIO if the region is > > + * secured else 0. > > + */ > > +static int nand_check_secure_region(struct nand_chip *chip, loff_t offset, u64 size) > > +{ > > + int i, j; > > + > > + /* Skip touching the secure regions if present */ > > + for (i = 0, j = 0; i < chip->nr_secure_regions; i++, j += 2) { > > + /* First compare the start offset */ > > + if (offset >= chip->secure_regions[j] && > > + (offset < chip->secure_regions[j] + chip->secure_regions[j + 1])) > > + return -EIO; > > + /* ...then offset + size */ > > + else if (offset < chip->secure_regions[i] && > > + (offset + size) >= chip->secure_regions[i]) > > + return -EIO; > > How about: > > const struct nand_secure_region *region = &chip->secure_regions[i]; > > if (offset + size <= region->offset || > offset >= region->offset + region->size) > continue; > > return -EIO; > I guess you mean this: /* Skip touching the secure regions if present */ for (i = 0; i < chip->nr_secure_regions; i++) { const struct nand_secure_region *region = &chip->secure_regions[i]; if (offset + size < region->offset || offset >= region->offset + region->size) continue; return -EIO; } return 0; > > + } > > + > > + return 0; > > +} > > + [...] > > diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h > > index 6b3240e44310..d385c4fe8b0f 100644 > > --- a/include/linux/mtd/rawnand.h > > +++ b/include/linux/mtd/rawnand.h > > @@ -1086,6 +1086,8 @@ struct nand_manufacturer { > > * NAND Controller drivers should not modify this value, but they're > > * allowed to read it. > > * @read_retries: The number of read retry modes supported > > + * @secure_regions: Array representing the secure regions > > + * @nr_secure_regions: Number of secure regions > > * @controller: The hardware controller structure which is shared among multiple > > * independent devices > > * @ecc: The ECC controller structure > > @@ -1135,6 +1137,8 @@ struct nand_chip { > > unsigned int suspended : 1; > > int cur_cs; > > int read_retries; > > + u64 *secure_regions; > > > Can you please define the following struct: > > struct nand_secure_region { > u64 offset; > u64 size; > }; > > instead of having an array of u64 where even entries encode the offset > and odd ones the size. > Hmm, I think you implicitly said this in your previous review as well and I somehow lost it. Will incorporate. So we'll have something like this in of_get_nand_secure_regions(): for (i = 0, j = 0; i < chip->nr_secure_regions; i++, j += 2) { of_property_read_u64_index(dn, "secure-regions", j, &chip->secure_regions[i].offset); of_property_read_u64_index(dn, "secure-regions", j + 1, &chip->secure_regions[i].size); } Thanks, Mani