linux-kernel - RE: [PATCH] mmc: truncate quirks' oemid to 8 bits

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]

Message-ID: <DM6PR04MB6575F41E713E2BD7C6D6023DFCA6A@DM6PR04MB6575.namprd04.prod.outlook.com>
Date:   Thu, 2 Nov 2023 13:37:36 +0000
From:   Avri Altman <Avri.Altman@....com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Dominique Martinet <dominique.martinet@...ark-techno.com>
CC:     Dominique Martinet <asmadeus@...ewreck.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Alex Fetters <Alex.Fetters@...min.com>
Subject: RE: [PATCH] mmc: truncate quirks' oemid to 8 bits

 
> On Thu, 26 Oct 2023 at 09:52, Dominique Martinet
> <dominique.martinet@...ark-techno.com> wrote:
> >
> > We now only capture 8 bits for oemid in card->cid.oemid, so quirks
> > that were filling up the full 16 bits up till now would no longer apply.
> 
> Huh, thanks for spotting this!
> 
> >
> > Work around the problem by only checking for the bottom 8 bits when
> > checking if quirks should be applied
> >
> > Fixes: 84ee19bffc93 ("mmc: core: Capture correct oemid-bits for eMMC
> > cards")
> 
> I wonder if the quirk approach is really the correct thing to do. I had a closer
> look around what has changed along the new versions of the MMC/eMMC
> specs, the below is what I found.
> 
> Before v4.3: OID [119:104] 16-bits.
> Between v4.3-v5.1: OID [111:104] 8-bits, CBX [113:112] 2-bits, reserved
> [119:114] 6-bits.
> Beyond v5.1A: OID [111:104] 8-bits, CBX [113:112] 2-bits, BIN [119:114] 6-
> bits.
> 
> OID: OEM/Application ID
> CBX: Device/BGA
> BIN: Bank Index Number
> 
> It looks to me that the offending commit (84ee19bffc93) should be reverted
> instead of trying to introduce some weird parsing of the card quirks.
Agreed.

> 
> In fact, up until v5.1 it seems not to be a problem to use 16-bits for the OID,
> as the CBX and the reserved bits are probably just given some fixed values by
> the vendors, right?
Or some random garbage...

> 
> Beyond v5.1A, we may have a problem as the BIN may actually be used for
> something valuable. Maybe Avri knows more here?
AFAIK, we don't use it.  But I can ask around.

Yeah, I think its best just to revert it.
If an eMMC vendor has an issue with this 16bits bogus oemid (Sandisk does) -
they can handle their oemid-specific quirks - I know I will.

Please note that it was picked by stable as well.

Thanks,
Avri
> 
> That said, if the offending commit is really needed to fix a problem, we need
> to figure out exactly what that problem is. The EXT_CSD_REV doesn't provide
> us with the exact version that the card is supporting, but at least we know if
> v5.1 and onwards is supported, so perhaps that can be used to fixup/improve
> the OID/CBX/BIN parsing.
> 
> Kind regards
> Uffe
> 
> > Link: https://lkml.kernel.org/r/ZToJsSLHr8RnuTHz@codewreck.org
> > Signed-off-by: Dominique Martinet
> > <dominique.martinet@...ark-techno.com>
> > Cc: stable@...r.kernel.org
> > Cc: Avri Altman <avri.altman@....com>
> > Cc: Ulf Hansson <ulf.hansson@...aro.org>
> > Cc: Alex Fetters <Alex.Fetters@...min.com>
> > ---
> > Notes:
> >  - mmc_fixup_device() was rewritten in 5.17, so older stable kernels
> >    will need a separate patch... I suppose I can send it to stable
> >    after this is merged if we go this way
> >  - struct mmc_cid's and mmc_fixup's oemid fields are unsigned shorts,
> >    we probably just want to make them unsigned char instead in which
> >    case we don't need that check anymore?
> >    But it's kind of nice to have a wider type so CID_OEMID_ANY can never
> >    be a match.... Which unfortunately my patch makes moot as
> >    ((unsigned short)-1) & 0xff will be 0xff which can match anything...
> >  - this could also be worked around in the _FIXUP_EXT macro that builds
> >    the fixup structs, but we're getting ugly here... Or we can just go
> >    for the big boom and try to fix all MMC_FIXUP() users in tree and
> >    call it a day, but that'll also be fun to backport.
> >
> >  drivers/mmc/core/quirks.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h
> > index 32b64b564fb1..27e0349e176d 100644
> > --- a/drivers/mmc/core/quirks.h
> > +++ b/drivers/mmc/core/quirks.h
> > @@ -211,8 +211,9 @@ static inline void mmc_fixup_device(struct
> mmc_card *card,
> >                 if (f->manfid != CID_MANFID_ANY &&
> >                     f->manfid != card->cid.manfid)
> >                         continue;
> > +               /* Only the bottom 8bits are valid in JESD84-B51 */
> >                 if (f->oemid != CID_OEMID_ANY &&
> > -                   f->oemid != card->cid.oemid)
> > +                    (f->oemid & 0xff) != (card->cid.oemid & 0xff))
> >                         continue;
> >                 if (f->name != CID_NAME_ANY &&
> >                     strncmp(f->name, card->cid.prod_name,
> > --
> > 2.39.2
> >
> >