Re: [PATCH v3 3/3] block: sed-opal: keyring support for SED keys

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2022-11-30 at 22:46 -0500, Ben Boeckel wrote:
> On Wed, Nov 30, 2022 at 09:19:25 -0600, Greg Joyce wrote:
> > On Wed, 2022-11-30 at 08:00 +0100, Hannes Reinecke wrote:
> > > On 11/30/22 00:25, gjoyce@xxxxxxxxxxxxxxxxxx wrote:
> > > > +	case OPAL_KEYRING:
> > > > +		/* the key is in the keyring */
> > > > +		ret = read_sed_opal_key(OPAL_AUTH_KEY, key-
> > > > >key,
> > > > OPAL_KEY_MAX);
> > > > +		if (ret > 0) {
> > > > +			if (ret > 255) {
> > > 
> > > Why is a key longer than 255 an error?
> > > If this is a requirement, why not move the check into
> > > read_sed_opal_key() such that one only has to check for
> > > ret < 0 on errors?
> > 
> > The check is done here because the SED Opal spec stipulates 255 as
> > the
> > maximum key length. The key length (key->key_len) in the existing
> > data
> > structures is __u8, so a length greater than 255 can not be
> > conveyed.
> > For defensive purposes, I though it best to check here.
> 
> Perhaps naming it `OPAL_MAX_KEY_LEN` would help clarify this?
> 
> --Ben

I'm not averse to changing it because it would be clearer. My concern
is that it's been OPAL_KEY_MAX for 5+ years (the original SED Opal
commit). Unless there is strong consensus to change it, I'm going to
leave it as the original name.

-Greg




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux