public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Peter Griffin <peter.griffin@linaro.org>
Cc: linux-scsi@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-fscrypt@vger.kernel.org,
	"Alim Akhtar" <alim.akhtar@samsung.com>,
	"Avri Altman" <avri.altman@wdc.com>,
	"Bart Van Assche" <bvanassche@acm.org>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	"André Draszik" <andre.draszik@linaro.org>,
	"William McVicker" <willmcvicker@google.com>
Subject: Re: [PATCH v2 6/6] scsi: ufs: exynos: Add support for Flash Memory Protector (FMP)
Date: Mon, 8 Jul 2024 13:26:30 -0700	[thread overview]
Message-ID: <20240708202630.GA47857@sol.localdomain> (raw)
In-Reply-To: <CADrjBPoWVq-eu4Wa6_hrkk067tnZGC82UCJDyjSRGoG254w6vg@mail.gmail.com>

Hi Peter,

On Thu, Jul 04, 2024 at 02:26:05PM +0100, Peter Griffin wrote:
> Do you know how these FMP registers (FMPSECURITY0 etc) relate to the
> UFSPR* registers set in the existing exynos_ufs_config_smu()? The
> UFS_LINK spec talks about UFSPR(FMP), so I had assumed the FMP support
> would be writing these same registers but via SMC call.
> 
> I think by the looks of things
> 
> #define UFSPRSECURITY 0x010
> #define UFSPSBEGIN0 0x200
> #define UFSPSEND0 0x204
> #define UFSPSLUN0 0x208
> #define UFSPSCTRL0 0x20C
> 
> relates to the following registers in gs101 spec
> 
> FMPSECURITY0 0x0010
> FMPSBEGIN0 0x2000
> FMPSEND0 0x2004
> FMPSLUN0 0x2008
> FMPSCTRL0 0x200C
> 
> And the SMC calls your calling set those same registers as
> exynos_ufs_config_smu() function. Although it is hard to be certain as
> I don't have access to the firmware code. Certainly the comment below
> about FMPSECURITY0 implies that :)
> 
> With that in mind I think exynos_ufs_fmp_init() function in this patch
> needs to be better integrated with the EXYNOS_UFS_OPT_UFSPR_SECURE
> flag and the existing exynos_ufs_config_smu() function that is
> currently just disabling decryption on platforms where it can access
> the UFSPR(FMP) regs via mmio.

I think that is all correct.  For some reason, on gs101 the FMP registers are
not accessible by the "normal world", and SMC calls need to be used instead.
The sequences of SMC calls originated from Samsung's Linux driver code for FMP.
So I know they are the magic incantations that are needed, but I don't have
access to the source code or documentation for them.  It does seem clear that
one of the things they must do is write the needed values to the FMP registers.

I'd hope that these same SMC calls also work on Exynos-based SoCs that do make
the FMP registers accessible to the "normal world", and therefore they can just
be used on all Exynos-based SoCs and ufs-exynos won't need two different code
paths.  But I don't have a way to confirm this myself.  Until someone is able to
confirm this, I think we need to make the FMP support depend on
EXYNOS_UFS_OPT_UFSPR_SECURE so that it doesn't conflict with
exynos_ufs_config_smu() which runs when !EXYNOS_UFS_OPT_UFSPR_SECURE.

- Eric

  reply	other threads:[~2024-07-08 20:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-02  7:25 [PATCH v2 0/6] Basic inline encryption support for ufs-exynos Eric Biggers
2024-07-02  7:25 ` [PATCH v2 1/6] scsi: ufs: core: Add UFSHCD_QUIRK_CUSTOM_CRYPTO_PROFILE Eric Biggers
2024-07-08 10:18   ` Peter Griffin
2024-07-02  7:25 ` [PATCH v2 2/6] scsi: ufs: core: fold ufshcd_clear_keyslot() into its caller Eric Biggers
2024-07-08 10:14   ` Peter Griffin
2024-07-02  7:25 ` [PATCH v2 3/6] scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_CRYPTO_ENABLE Eric Biggers
2024-07-08 10:06   ` Peter Griffin
2024-07-02  7:25 ` [PATCH v2 4/6] scsi: ufs: core: Add fill_crypto_prdt variant op Eric Biggers
2024-07-08 10:12   ` Peter Griffin
2024-07-02  7:25 ` [PATCH v2 5/6] scsi: ufs: core: Add UFSHCD_QUIRK_KEYS_IN_PRDT Eric Biggers
2024-07-08 10:01   ` Peter Griffin
2024-07-02  7:25 ` [PATCH v2 6/6] scsi: ufs: exynos: Add support for Flash Memory Protector (FMP) Eric Biggers
2024-07-02 22:06   ` Bart Van Assche
2024-07-04 13:26   ` Peter Griffin
2024-07-08 20:26     ` Eric Biggers [this message]
2024-07-08 23:49       ` Eric Biggers
2024-07-10  5:52         ` Alim Akhtar
2024-07-10 22:27           ` Eric Biggers
2024-07-02 22:06 ` [PATCH v2 0/6] Basic inline encryption support for ufs-exynos Bart Van Assche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240708202630.GA47857@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=alim.akhtar@samsung.com \
    --cc=andre.draszik@linaro.org \
    --cc=avri.altman@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=peter.griffin@linaro.org \
    --cc=willmcvicker@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox