Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1069793pxa; Sat, 22 Aug 2020 09:55:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJykGKcV8epaRdGllQFbl1ns0yJ/NI6vAFQy/y2iCLfMqRpZGzuWEW+ghkRdm2KBxL76ctEx X-Received: by 2002:a17:906:7d6:: with SMTP id m22mr7669650ejc.229.1598115329851; Sat, 22 Aug 2020 09:55:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598115329; cv=none; d=google.com; s=arc-20160816; b=l4W3fDb/mFGn4gbIzlTp7uhuaQtQYo/5GyGxlhr5ddE7ow5k39zAKOFnHUSwpFEzAY 9LNcKCMrXMKAkpbo5LR+h6R4k07ei/fM9P3TZIps7+2YQDDsezKPA06YNbKUOgcJnKv3 OLoe0tYs808KQEOV+ZHl0GWIIV244VuMdW5mB0EB8MpqfBDsDWeBBPBwvIc1YaqSYhov kpq+Dt72b0BYb0mo3fPtMwT5FRx22yRexHyG2sUvvVmjeJmIhkUn3DZEQxpVJfMciZxI eFSQBkstWW0cwqoYLXm7onhTIv5IKvCe+EOFzAOYrLjwiENZUkj2751b3i4tYsWZGQ1D lTRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=lErADMoG0+zvYcQL2P4ZcCOGRn0ayCv9D79oPkldRNI=; b=TMrkNBnYs5QkoEWGkZ+RbMd32NhOh3+gxERRP04t8wk2FHBaVV9yQ6W+GXxy74O9Cw 1LHl0+niaOgg5KjVkCWmdzaXFoQ7JP4ihgsWq7RbIGesbU7yNpYjGUTJi1fx+/c0G27F 69NwM9/Cw7a+YOoMsLEJRty2M2If5kzipUEWHGfmHgOGWHyB0s50RbPODIBEuJINjzaS DnXHLL2X7/ySNdS4rxJO7dpwjKHQnDzdEyMBob1gurqhmOL5XA7sd4hj9YbEG4FkWPIu Mrk5nsakkcvimLCdkGLW5RTtoTQJ2zjocBgUVONZz8CYGU3zUZpjI4+662P2jUsDy0Ee 4AAw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lt22si3514096ejb.376.2020.08.22.09.55.03; Sat, 22 Aug 2020 09:55:29 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728360AbgHVQGa (ORCPT + 99 others); Sat, 22 Aug 2020 12:06:30 -0400 Received: from mout.kundenserver.de ([217.72.192.75]:48665 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728219AbgHVQGZ (ORCPT ); Sat, 22 Aug 2020 12:06:25 -0400 Received: from mail-qt1-f182.google.com ([209.85.160.182]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.145]) with ESMTPSA (Nemesis) id 1M4s8v-1kAtTe0jgd-0020EX for ; Sat, 22 Aug 2020 18:06:21 +0200 Received: by mail-qt1-f182.google.com with SMTP id s16so3381695qtn.7 for ; Sat, 22 Aug 2020 09:06:20 -0700 (PDT) X-Gm-Message-State: AOAM530QRFTEqMiRdbIsstZiCL3bDmBBQ6uOFWsWHI7VZL9xML03OHku VJHtf3ik2cEn0c60TJ8oQF7OstU1zL9odF4oeLo= X-Received: by 2002:ac8:688e:: with SMTP id m14mr7377100qtq.7.1598112379995; Sat, 22 Aug 2020 09:06:19 -0700 (PDT) MIME-Version: 1.0 References: <20200819065721.GA1375436@lahna.fi.intel.com> <20200819091123.GE1375436@lahna.fi.intel.com> In-Reply-To: <20200819091123.GE1375436@lahna.fi.intel.com> From: Arnd Bergmann Date: Sat, 22 Aug 2020 18:06:03 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mtd: spi-nor: intel-spi: Do not try to make the SPI flash chip writable To: Mika Westerberg Cc: Daniel Gutson , Tudor Ambarus , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Boris Brezillon , linux-mtd , "linux-kernel@vger.kernel.org" , Alex Bazhaniuk , Richard Hughes , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:LIAa7epBaUs52AM+l/YygUBk8GcVWlsOsOaIYeWox/KVZFZTkTg g+MOzOcjk/cdLKyXgNiy2zpHgVlP+P8fx7IA+6SC6GFgytPR1utNBxuxX/vsRB76tzZ0w1e cL8ZTJrmuquUFjpICMe1hduzwYJrKyR820oT2PjYnF3n6+1b29TaX/tL7BN6GNaE/zo61wo UZK+6bsed/kqcMQ9tAxJw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:NL2cuBKNHo0=:PTQ1vEVf/Pbpmo8S2czCL+ 7Lf63EOX2HnvNYmqO0joFwHwN6OCyCFNTaisxVfyKhkDU0SfJ1nscBtDKRAwbgQEtViQZlstK n0zvvuQxvJtkp4eUh/gmr3t/6wAkstatKP4gGjBLzG0c4O08u2z9/5tgoVzC2ycmaCsrIlTuF pV063Z1+bJRCQDX9GcWIcJ/h5XLKIgCyF8njpfKsDtZE7huxCxTezcNKWC1ghAJqE4RDgJeZN ILXaH2OWVUwHX5DhFaW+0VrhBrE8EjpLMRBSFkPDoaQzhruGZhoB46a1Jd8L59jV0vUmGG8Kz tXSZTgEYTG5SmUzDXO8SdnnvsdJ7URO4mJGrchkxqrVGOw9/OsrgqM9AB0KFctTSPnAozSKJm Bf7i5y4XHg3iiSUdQkQra/CEuWuJmYxXykJttHsg7ECKnApRNsJ/1RBxRktiBYBdUOw9pjr1+ ARYuqKeHWyOuTkKAynZ9kAodWIuZMVqq6DX2J743bOgFuwWZVmXLVS8w4zhdMinsGj6PiJqOa Nof0we7rQasgMuLYvr92C/X7zC/2bzV30zhwA4IRiscNFKAJqgATRCHcIpEowugZ/Mv6vIdPA ddgvWMBsBoiNNS9fkIZBANfUVL5/Uxh4ZrRBVsA8lg8E/82PnYR1XIpl8C0Vtt0MAx0lqdaiZ V86Q/8OvQFuWkEzobVKm92sqEW3OX/v6K5y9cXljPMkmhC7p1q+7kvcbM8/8gv6BTGixsxOay hPhOymbSkBkbdlzqJvVwfkZyoDm1OMvoufgHKMTsVTLpN8UoSPJJD8TFNV9oSZfwufPXFGETO yroQOBSajpnARmeH7jYeC8FRyYLrfMp9T2dlBQguEzReFZLykTHR6PQg1t9MDu2NVwQC+JCyJ NHV2B0iUPXYiaotD5rDaYYz5Ib/2Ui7JYRgRfmK/3OJzbCRLP6iWGq8rtVKoDjOH8306IRO0G /jOEClElaXbRe9ODbI6jwTs35RlF8AZwfq/8EJeHftg9SGXgb3CoKtbgLQme57DWvkwA3mCE7 vnpr7ctBoI7NA8/6SNN5Hj4xlWA1jHCwrxauylMkcwKy/B/moNFAhthYRkSvbdVq1ehDPcgDI lRFh+P6PwVEmFa92+uNuRvBcGlEdxx8H4eXZJJqPLUXyYPV/C+SJaqHbaTLi3fvOcONuypfzp tOWVusBvGoox6SMgxR1mpnY4/BVR+4KdR15xTYcNx4omFIEb4/rPNywHCBqPCDHOpsWvaKgBH 6/Agbb2w7MUIwecdb Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 19, 2020 at 11:11 AM Mika Westerberg wrote: > On Wed, Aug 19, 2020 at 10:38:24AM +0200, Arnd Bergmann wrote: > > On Wed, Aug 19, 2020 at 8:57 AM Mika Westerberg wrote: > > > > Actually thinking about this bit more, to make PCI and the platform > > > parts consistent we can make the "writeable" control this for the PCI > > > part as well. So what if we add a callback to struct intel_spi_boardinfo > > > that the PCI driver populates and then the "core" driver uses to enable > > > writing when "writeable" is set to 1. > > > > If you are really worried about the write protection being bypassed by > > a different driver or code injection, the best way would seem to be to > > only enable writing in the mtd write callback and disable it immediately > > after the write is complete. I still don't see why this hardware would > > be more susceptible to this kind of attack than other drivers though, > > as it already has the safeguard against writing through the MTD layer > > without the module parameter. > > Hmm, is there already a mechanism at the MTD level to prevent writes? If > that's the case then sure we can use that instead. The mtd core just checks both the permissions on the device node (which default to 0600 without any special udev rules) and the MTD_WRITEABLE on the underlying device that is controlled by the module parameter in case of intel-spi{,-platform,-pci}.c. Arnd