lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 Mar 2024 15:38:33 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: "Jorge Ramirez-Ortiz, Foundries" <jorge@...ndries.io>
Cc: Jens Wiklander <jens.wiklander@...aro.org>, Tomas Winkler <tomas.winkler@...el.com>, 
	Dominique Martinet <asmadeus@...ewreck.org>, Ulf Hansson <ulf.hansson@...aro.org>, 
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Dominique Martinet <dominique.martinet@...ark-techno.com>, stable@...r.kernel.org
Subject: Re: [PATCH] mmc: part_switch: fixes switch on gp3 partition

On Wed, Mar 6, 2024 at 3:22 PM Jorge Ramirez-Ortiz, Foundries
<jorge@...ndries.io> wrote:

> I still cant grasp how "target_part = idata->rpmb->part_index" is
> helping in the design.
>
> What happens when:
> 1) EXT_CSD_PART_CONFIG_ACC_MASK > part_index > EXT_CSD_PART_CONFIG_ACC_RPMB
> target_part now could be indicating a GP instead of an RPMB leading to failures.
>
> 2) part_index <= EXT_CSD_PART_CONFIG_ACC_RPMB
> loses the part_index value .
>
> So part_index should be larger than EXT_CSD_PART_CONFIG_ACC_MASK even
> though the comment indicates it starts at 0?
>
> /**
>  * struct mmc_rpmb_data - special RPMB device type for these areas
>  * @dev: the device for the RPMB area
>  * @chrdev: character device for the RPMB area
>  * @id: unique device ID number
>  * @part_index: partition index (0 on first)    <---------------------
>  * @md: parent MMC block device
>  * @node: list item, so we can put this device on a list
>  */
> struct mmc_rpmb_data {
>         struct device dev;
>         struct cdev chrdev;
>         int id;
>
> is it just possible that "target_part = idata->rpmb->part_index" just
> needs to be shifted to avoid issues?
>
> I think the fix to the regression I introduced could perhaps address
> this as well.

I have no clue how the regression happened really ... heh.

We should probably rename it part_cfg because that is what we
store in it, it's assigned from card->part[idx].part_cfg.

Then the id field in mmc_rpmb_data should be deleted along
with all the IDA counter code etc and the partition name hardcoded
to be "0" as there will never be anything else.

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ