From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CBB5C15E97; Mon, 30 Sep 2024 19:40:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.142.180.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727725212; cv=none; b=EsaHO8zl3f9bMPb2CNdKdeDvNFxqenrHDqQlqyyYjhSQ4Py8N2SuGYwZRy5LaMI9kxgOEecwVpf+HfSxCvaAQT5TrtZBSUTPzEF62+3oK0DocioiWV7wCEfdQ7fHedf6GqaN+ZAFWq1VJKD9qqG/D5pY7dIEbu5muoQQ8hqUvyg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727725212; c=relaxed/simple; bh=e39O9i8KNuQKU6yo245+NtHRI5zD3SznBknI0fyUa7U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tuL8PJzGvfsJQxlfA5PXXJPE0bcEIRPe25WquvfAMIplLEdrB/eXp+avRvFJSrI4hlzGypV7r2WqowmfD8ROyf1/CzJNJauOvJ+MvfAx6dzdYD10z/KSnYBJdhq79g0/+RZ6+urEKVL5/J70wm1EjQw80fqKxA2TJiVxXUZ4Kgo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org; spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.98) (envelope-from ) id 1svMFR-0000000050w-0VwY; Mon, 30 Sep 2024 19:39:57 +0000 Date: Mon, 30 Sep 2024 20:39:48 +0100 From: Daniel Golle To: Richard Weinberger Cc: chengzhihao1 , Miquel Raynal , Vignesh Raghavendra , robh , Krzysztof Kozlowski , Conor Dooley , John Crispin , linux-mtd , devicetree , linux-kernel Subject: Re: [PATCH RFC 2/2] mtd: ubi: add support for protecting critical volumes Message-ID: References: <251386789.117942.1727612762462.JavaMail.zimbra@nod.at> <364911897.123906.1727721820227.JavaMail.zimbra@nod.at> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <364911897.123906.1727721820227.JavaMail.zimbra@nod.at> On Mon, Sep 30, 2024 at 08:43:40PM +0200, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- > > Von: "chengzhihao1" > >>> Von: "Daniel Golle" > >>> Allow the boot firmware to define volumes which are critical for the > >>> system to boot, such as the bootloader itself if stored inside a UBI > >>> volume. Protect critical volumes by preventing the user from removing, > >>> resizing or writing to them, and also prevent the UBI device from > >>> being detached if a critical volume is present. > >> > >> I agree with the doubts raised in patch 1/2, if userspace is so hostile > >> to delete system partitions, there is little hope. > >> But I'm still open for discussion. > > > > Yes, I agree that it is meaningful to prevent user from operating > > volumes accidently. How about doing that by some existing methods? Eg. > > selinux(Design sepolicy for ioctl cmd). > > Another thought, do we really need to enforce this in kernel space? > Teaching ubi-tools to be super careful with some volumes is also an option. > > like a ubirmvol ... --i-know-what-im-doing. True, enforcement doesn't need to happen in kernel (though I think it's nicer, but really just a matter of taste, I guess). ubi-tools would still need to be able to recognize critical volumes somehow, and that could be done by checking if the 'volume-is-critical' property is present in /sys/class/ubi/ubi*_*/of_node/ If you prefer going down that road instead I will work on patches for git.infradead.org/mtd-utils.git instead.