mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Harald Mommer <hmo@opensynergy.com>
To: "Alex Bennée" <alex.bennee@linaro.org>, linux-kernel@vger.kernel.org
Cc: maxim.uvarov@linaro.org, joakim.bech@linaro.org,
	ulf.hansson@linaro.org, ilias.apalodimas@linaro.org,
	arnd@linaro.org, ruchika.gupta@linaro.org,
	tomas.winkler@intel.com, yang.huang@intel.com,
	bing.zhu@intel.com, Matti.Moell@opensynergy.com,
	linux-mmc@vger.kernel.org, linux-scsi@vger.kernel.org,
	Alexander Usyskin <alexander.usyskin@intel.com>
Subject: Re: [PATCH v2 4/4] tools rpmb: add RPBM access tool
Date: Thu, 16 Jun 2022 15:13:02 +0200	[thread overview]
Message-ID: <c72a13b3-d3c9-7502-07fe-ebb76cb0bb3d@opensynergy.com> (raw)
In-Reply-To: <20220405093759.1126835-5-alex.bennee@linaro.org>

Hello,

On 05.04.22 11:37, Alex Bennée wrote:
> +/*
> + * Utility functions
> + */
> +static int open_dev_file(const char *devfile, struct rpmb_ioc_cap_cmd *cap)
> +{
> ...
> +	rpmb_dbg("RPMB rpmb_target = %d\n", cap->target);
> +	rpmb_dbg("RPMB capacity    = %d\n", cap->capacity);
> +	rpmb_dbg("RPMB block_size  = %d\n", cap->block_size);
> +	rpmb_dbg("RPMB wr_cnt_max  = %d\n", cap->wr_cnt_max);
> +	rpmb_dbg("RPMB rd_cnt_max  = %d\n", cap->rd_cnt_max);
> +	rpmb_dbg("RPMB auth_method = %d\n", cap->auth_method);

The previously present device_type has already gone. Do we loose an 
opportunity to inform the user about anything which may not be virtio 
RPMB in the future or is this intentional? A new device type VIRTIO_RPMB 
instead and keeping the door open for UFS, NVMe, eMMC etc.?

And if the removal was intentional: rpmb_target, block_size, 
auth_method: Still needed and if so for what is it good for?

> ...
> +}
> +
> +static struct virtio_rpmb_frame * vrpmb_alloc_frames(int n)
> +{
> +	struct virtio_rpmb_frame *frames;
> +
> +	frames = calloc(n, sizeof(struct virtio_rpmb_frame));
> +	if (frames)
> +		memset(frames, 0, n *  sizeof(struct virtio_rpmb_frame));
Very minor: calloc() already zeroes.
> +	return frames;
> +}
> +

/*
+ * To read blocks we receive a bunch of frames from the vrpmb device
+ * which we need to validate and extract the actual data into
+ * requested buffer.
+ */
+static int vrpmb_read_blocks(int dev_fd, void *key, int addr, int count, void *data, int len)
+{
+...
+	ret = ioctl(dev_fd, RPMB_IOC_RBLOCKS_CMD, &cmd);
+	if (ret < 0) {
+		rpmb_err("rblocks ioctl failure %d: %s.\n", ret,
+			 strerror(errno));
+		goto out;
+	}

The (older) rpmb tool always puzzles me with complaining about the mismatch MAC when there was also a result != VIRTIO_RPMB_RES_OK.
I guess the ioctl() returns 0 if the ioctl() as such succeeded but there is an error code indicated in the frame.
Consider adding to print the result if it indicated a problem.

I can remember the old tool used the result of the last frame for this purpose which was probably not a good choice, not sure why this was that way, probably the first frame would be a better choice.

+	for (i = 0; i < count; i++) {
+		struct virtio_rpmb_frame *f = &frames[i];
+
+		vrpmb_dump_frame("block data", f);
+
+		if (key) {
+			ret = vrpmb_check_mac(key, f, 1);
+			if (ret) {
+				rpmb_err("%s: check mac error frame %d/%d\n", __func__, i, ret);
+				break;
+			}
+		}
+
+		memcpy(data, &f->data, RPMB_BLOCK_SIZE);
+		data += RPMB_BLOCK_SIZE;
+	}
+	ret = 0;
+
+ out:
+	free(frames);
+	return ret;
+}
+
+
+static void *read_key(const char *path)
+{
+	int key_fd = open_rd_file(path, "key file");
+	void *key;
+
+	if (key_fd < 0)
+		return NULL;
+
+	key = malloc(RPMB_KEY_SIZE);

Very minor: There's not a single free() for key in the code. Plays no 
role here as the program runs only for a fraction of a second, just saw 
it. You are making your life harder as necessary by using dynamic memory 
when it can be avoided, all those NULL pointer checks and the free(s) 
which have to be done...
> +
> +	if (!key) {
> +		rpmb_err("out of memory for key\n");
> +		return NULL;
> +	}
> +
> +	if (read(key_fd, key, RPMB_KEY_SIZE) != RPMB_KEY_SIZE) {
> +		rpmb_err("couldn't read key (%s)\n", strerror(errno));
> +		return NULL;
> +	}
> +
> +	close(key_fd);
> +	return key;
> +}
> +
>
> +
> +static const struct rpmb_cmd cmds[] = {
> +	{
> +		"get-info",
> +		op_get_info,
> +		"<RPMB_DEVICE>",
> +		"    Get RPMB device info\n",
> +	},
> +	{
> +		"program-key",
> +		op_rpmb_program_key,
> +		"<RPMB_DEVICE> <KEYFILE>",
> +		"    Program authentication KEYFILE\n"
> +		"    NOTE: This is a one-time programmable irreversible change.\n",
> +	},
> +	{
> +		"write-counter",
> +		op_rpmb_get_write_counter,
> +		"<RPMB_DEVICE>",
> +		"    Rertrive write counter value from the <RPMB_DEVICE> to stdout.\n"

Optional parameter explanation [KEYFILE] got lost in write-counter.

> +	},
> +	{
> +		"write-blocks",
> +		op_rpmb_write_blocks,
> +		"<RPMB_DEVICE> <address> <block_count> <DATA_FILE> <KEYID>",
> +		"    <block count> of 256 bytes will be written from the DATA_FILE\n"
> +		"    to the <RPMB_DEVICE> at block offset <address>.\n"
> +		"    When DATA_FILE is -, read from standard input.\n",
Puzzling naming change. The KEYID is indeed the <KEYFILE>.
> +	},
> +	{
> +		"read-blocks",
> +		op_rpmb_read_blocks,
> +		"<RPMB_DEVICE> <address> <blocks count> <OUTPUT_FILE>",
> +		"    <block count> of 256 bytes will be read from <RPMB_DEVICE>\n"
> +		"    to the OUTPUT_FILE\n"
> +		"    When OUTPUT_FILE is -, write to standard output\n",

Here also the optional parameter explanation [KEYFILE] got lost in 
read-blocks.

For people not knowing the tool trying to get into RPMB a complete and 
consistent help is helpful I can still remember when I was in the 
situation to understand more playing around with the (older) tool.

> +	},
> +
> +	{ NULL, NULL, NULL, NULL }
> +};

-- 
Dipl.-Ing. Harald Mommer
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

Phone:  +49 (30) 60 98 540-0 <== Zentrale
Fax:    +49 (30) 60 98 540-99
E-Mail: harald.mommer@opensynergy.com

www.opensynergy.com

Handelsregister: Amtsgericht Charlottenburg, HRB 108616B
Geschäftsführer/Managing Director: Regis Adjamah


  reply	other threads:[~2022-06-16 13:14 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-05  9:37 [PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver Alex Bennée
2022-04-05  9:37 ` [PATCH v2 1/4] rpmb: add Replay Protected Memory Block (RPMB) subsystem Alex Bennée
2022-04-05 21:59   ` Bart Van Assche
2022-04-06 11:21     ` Alex Bennée
2022-04-05  9:37 ` [PATCH v2 2/4] char: rpmb: provide a user space interface Alex Bennée
2022-06-16 15:09   ` Harald Mommer
2022-06-16 19:21   ` Arnd Bergmann
2022-04-05  9:37 ` [PATCH v2 3/4] rpmb: create virtio rpmb frontend driver Alex Bennée
2022-06-16 15:44   ` Harald Mommer
2022-04-05  9:37 ` [PATCH v2 4/4] tools rpmb: add RPBM access tool Alex Bennée
2022-06-16 13:13   ` Harald Mommer [this message]
2022-04-05 14:54 ` [PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver Bean Huo
2022-04-05 15:43   ` Alex Bennée
2022-04-05 17:03     ` Bean Huo
2022-04-06 11:22       ` Alex Bennée
2022-04-06 17:19         ` Bean Huo
2022-04-06 17:32           ` Bart Van Assche
2022-04-06 18:12             ` Bean Huo
2022-04-06 20:20               ` Bart Van Assche
2022-04-07 16:28                 ` Bean Huo
2022-04-06 17:27         ` Bean Huo
2022-04-22 14:21 ` Alex Bennée
     [not found] ` <20230531191007.13460-1-shyamsaini@linux.microsoft.com>
2023-06-01  1:02   ` Zhu, Bing
2023-06-01  5:31     ` Ilias Apalodimas
2023-06-01  5:48       ` Sumit Garg
2023-06-02  8:25         ` Ilias Apalodimas
2023-06-12 17:06           ` Jens Wiklander
2023-06-13  0:49           ` Shyam Saini
2023-06-13 16:47     ` Shyam Saini

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=c72a13b3-d3c9-7502-07fe-ebb76cb0bb3d@opensynergy.com \
    --to=hmo@opensynergy.com \
    --cc=Matti.Moell@opensynergy.com \
    --cc=alex.bennee@linaro.org \
    --cc=alexander.usyskin@intel.com \
    --cc=arnd@linaro.org \
    --cc=bing.zhu@intel.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=joakim.bech@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=maxim.uvarov@linaro.org \
    --cc=ruchika.gupta@linaro.org \
    --cc=tomas.winkler@intel.com \
    --cc=ulf.hansson@linaro.org \
    --cc=yang.huang@intel.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

all inboxes | Powered by JetHome®