Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2874326pxb; Tue, 9 Mar 2021 13:13:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJx9NNpxXUNqIsdldkw+ItaioXPL1wN2GcoDrYbGigxEUILFTi+rWWsOIF83Ho1vzZ40kSp5 X-Received: by 2002:a17:906:acb:: with SMTP id z11mr4930ejf.193.1615324401247; Tue, 09 Mar 2021 13:13:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615324401; cv=none; d=google.com; s=arc-20160816; b=MaUB9oiBAOIBSpcOD8X7hpT+FYBYZ3DHfM2Fjj0XLugs5YzQHzCg+Kr8AA6sJq81We GzZoQVdpT9DSix7rm5KLM+hHDWNHFWK5Ne1OrYU832iNdfuKVkThvjebBMRRRjR8YR0N P/YJCGHwLnDQ99DBQb/xDOBX/er7DHmXuHG11kRaRSPN17IAY8EyfyKyFu+T+hEy/FE4 HP544fpcMcMB8nVgR8gAywGjTw0Tjifn5UUHpiLBJbDjKrl2Bp2JgMS3/FJA84buKMF6 hZ4e3RS/BqFViwAutZKhmtVjjmKOSMUCbTGcyBFy+u48iQqJburT8tzFSM76X2FOB3Zx eZFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to; bh=fL+TBhAoATkp9xspzzML1/KWeqYbtPIi9RtRKX4L798=; b=ee5SS5olsuqDMZmaRCDpBAqLEn570i6RXhUnj1SYcMMGh57cHGKRZ6+TVocvmxO/ha 5eM7wXqdCD1bKyGnpcFE0QulBzfoPpPQuSDQaIrdMsA6URCPIBQsqqm9wvy5TMPe1w6l ymn8NViPG+jRLXVmQNkjBVMayNgvMcwk2wfkAIAR0wEqNTmUg43trbkhmFe4+cT4Zcjr jk4N/bfXy3u1LcNUf77SFPjwcU8tkNEw0Gty77aSu+ADWC1GmEBWgvwmGTHPgIWi/yQI igvwN76Ew0PxZT+2Rvli4axEoFC0bampqXroBbREAahI07tvkWuRVu6NAYxVnA63QTFn TMLw== 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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s9si10476131edc.296.2021.03.09.13.12.31; Tue, 09 Mar 2021 13:13:21 -0800 (PST) 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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231594AbhCIVKW (ORCPT + 99 others); Tue, 9 Mar 2021 16:10:22 -0500 Received: from marcansoft.com ([212.63.210.85]:33004 "EHLO mail.marcansoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230173AbhCIVJ6 (ORCPT ); Tue, 9 Mar 2021 16:09:58 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 1C1D141982; Tue, 9 Mar 2021 21:09:35 +0000 (UTC) To: Linus Walleij , Arnd Bergmann , keyrings@vger.kernel.org, David Howells , Jarkko Sakkinen Cc: Joakim Bech , =?UTF-8?Q?Alex_Benn=c3=a9e?= , "linux-kernel@vger.kernel.org" , Maxim Uvarov , Ilias Apalodimas , ruchika.gupta@linaro.org, "Winkler, Tomas" , yang.huang@intel.com, bing.zhu@intel.com, Matti.Moell@opensynergy.com, hmo@opensynergy.com, linux-mmc , linux-scsi , linux-nvme@vger.kernel.org, Ulf Hansson , Arnd Bergmann References: <20210303135500.24673-1-alex.bennee@linaro.org> <20210303135500.24673-2-alex.bennee@linaro.org> <20210305075131.GA15940@goby> From: Hector Martin Subject: Re: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem Message-ID: <6c542548-cc16-af68-c755-df52bd13b209@marcan.st> Date: Wed, 10 Mar 2021 06:09:34 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: es-ES Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/03/2021 01.20, Linus Walleij wrote: > I suppose it would be a bit brutal if the kernel would just go in and > appropriate any empty RPMB it finds, but I suspect it is the right way > to make use of this facility given that so many of them are just sitting > there unused. Noone will run $CUSTOM_UTILITY any more than they > run the current RPMB tools in mmc-tools. AIUI the entire thing relies on a shared key that is programmed once into the RPMB device, which is a permanent operation. This key has to be secure, usually stored on CPU fuses or derived based on such a root of trust. To me it would seem ill-advised to attempt to automate this process and have the kernel do a permanent take-over of any RPMBs it finds (with what key, for one?) :) For what it's worth, these days I think Apple uses a separate, dedicated secure element for replay protected storage, not RPMB. That seems like a sane approach, given that obviously Flash storage vendors cannot be trusted to write security-critical firmware. But if all you have is RPMB, using it is better than nothing. The main purpose of the RPMB is, as the name implies, replay protection. You can do secure storage on any random flash with encryption, and even do full authentication with hash trees, but the problem is no matter how fancy your scheme is, attackers can always dump all memory and roll your device back to the past. This defeats stuff like PIN code attempt limits. So it isn't so much for storing crypto keys or such, but rather a way to prevent these attacks. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub