All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Avri Altman <Avri.Altman@wdc.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>
Subject: Re: [RFC PATCH 1/3] mmc: core: validate user input for RPMB block count
Date: Thu, 22 Nov 2018 15:05:10 +0100	[thread overview]
Message-ID: <20181122140510.GA1070@kunai> (raw)
In-Reply-To: <SN6PR04MB49251A94A2BF6E60D12919E1FCDB0@SN6PR04MB4925.namprd04.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

Hi Avri,

thanks for your comments!

> > For RPMB, block count is a non-zero 16 bit wide number. Reject invalid
> Actually this is not what limits the number of rpmb frames to be read,
> As those are not indicated in the block_count field of the rpmb frame,
> But in CMD23.
> While it is true that by eMMCv52 RPMB_SIZE_MULT max value is 0x80,
> Which limits the RPMB are to 16M, or 65535 rpmb frames,
> I don't think that it is up to the host to validate the rpmb frame content - 

I wanted to fix the following issue:

Currently, in to-be-removed mmc_set_blockcount() we have:

	cmd.arg = blockcount & 0x0000FFFF;

So, sending a IOCTL with a value of 65537 will silently(!) produce a
block count of 1. I didn't like this.

I don't have the eMMC specs on this computer but I recall it is defined
somewhere that there are 2 bytes reserved for it in the packet frame?

But yes, standards may be extended, so I am not opposed to fill in
bigger numbers than 16 bit and let the card handle the error.

So you suggest dropping this patch and keep the others, did I get this
right? Would be fine with me.

Regards,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-11-23  0:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20 23:08 [RFC PATCH 0/3] mmc: refactor RPMB block count handling Wolfram Sang
2018-11-20 23:08 ` [RFC PATCH 1/3] mmc: core: validate user input for RPMB block count Wolfram Sang
2018-11-22 12:15   ` Avri Altman
2018-11-22 14:05     ` Wolfram Sang [this message]
2018-11-22 15:57       ` Avri Altman
2018-11-22 23:34         ` Wolfram Sang
2018-11-25 22:12   ` Clément Péron
2018-11-20 23:08 ` [RFC PATCH 2/3] mmc: core: use mrq->sbc when sending CMD23 for RPMB Wolfram Sang
2018-11-25 22:13   ` Clément Péron
2018-11-20 23:08 ` [RFC PATCH 3/3] mmc: core: remove obsolete mmc_set_blockcount() function Wolfram Sang
2018-11-25 22:13   ` Clément Péron
2018-11-21  0:31 ` [RFC PATCH 0/3] mmc: refactor RPMB block count handling Ulf Hansson
2018-11-21  2:35   ` Wolfram Sang
2018-11-22 10:35     ` Clément Péron
2018-11-24 14:26       ` Clément Péron
2018-11-24 21:37         ` Wolfram Sang
2018-11-25 22:11           ` Clément Péron
2018-11-26  9:38             ` Wolfram Sang

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=20181122140510.GA1070@kunai \
    --to=wsa@the-dreams.de \
    --cc=Avri.Altman@wdc.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=wsa+renesas@sang-engineering.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.