public inbox for linux-efi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: linux-fsdevel@vger.kernel.org, linux-efi@vger.kernel.org,
	Ard Biesheuvel <ardb@kernel.org>, Jeremy Kerr <jk@ozlabs.org>
Subject: Re: [PATCH 3/6] efivarfs: make variable_is_present use dcache lookup
Date: Tue, 10 Dec 2024 12:27:28 -0500	[thread overview]
Message-ID: <cbb9303498007cc78ef80f84cbf029e4f84a9b96.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAAH4kHaDnzY_KWkRy+fGzxOh5b9oViSfSWZ4CcQSa8n3dF2v2A@mail.gmail.com>

On Tue, 2024-12-10 at 09:14 -0800, Dionna Amalie Glaze wrote:
> On Tue, Dec 10, 2024 at 9:03 AM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> 
> >  extern const struct file_operations efivarfs_file_operations;
> >  extern const struct inode_operations
> > efivarfs_dir_inode_operations;
> > @@ -64,4 +66,6 @@ extern struct inode *efivarfs_get_inode(struct
> > super_block *sb,
> >                         const struct inode *dir, int mode, dev_t
> > dev,
> >                         bool is_removable);
> > 
> > +
> > +
> 
> Unnecessary

I can remove the extra line.

> >  #endif /* EFIVAR_FS_INTERNAL_H */
> > diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
> > index b22441f7f7c6..dc3870ae784b 100644
> > --- a/fs/efivarfs/super.c
> > +++ b/fs/efivarfs/super.c
> > @@ -181,6 +181,26 @@ static struct dentry
> > *efivarfs_alloc_dentry(struct dentry *parent, char *name)
> >         return ERR_PTR(-ENOMEM);
> >  }
> > 
> > +bool efivarfs_variable_is_present(efi_char16_t *variable_name,
> > +                                 efi_guid_t *vendor, void *data)
> > +{
> > +       char *name = efivar_get_utf8name(variable_name, vendor);
> > +       struct super_block *sb = data;
> > +       struct dentry *dentry;
> > +       struct qstr qstr;
> > +
> > +       if (!name)
> > +               return true;
> 
> Why is this true? I understand the previous implementation would have
> hit a null dereference trying to calculate strsize1 on null, so this
> isn't worse, but if we considered its length to be 0, it would not be
> found.

Because for safety on failure we need to assume a collision.  kmalloc
failing will already have dropped an error message so adding another
here (particularly when the log will likely be filling up with these
because we're in a critical memory shortage situation) would seem to be
overkill.  The memory allocation will never fail ordinarily and if it
does the system will be degrading fast, so EFI filesystem variable
collision will be the least of the problem.

Regards,

James


  reply	other threads:[~2024-12-10 17:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-10 17:02 [PATCH 0/6] convert efivarfs to manage object data correctly James Bottomley
2024-12-10 17:02 ` [PATCH 1/6] efivarfs: remove unused efi_varaible.Attributes and .kobj James Bottomley
2024-12-10 17:02 ` [PATCH 2/6] efivarfs: add helper to convert from UC16 name and GUID to utf8 name James Bottomley
2024-12-10 17:02 ` [PATCH 3/6] efivarfs: make variable_is_present use dcache lookup James Bottomley
2024-12-10 17:14   ` Dionna Amalie Glaze
2024-12-10 17:27     ` James Bottomley [this message]
2024-12-23 20:20   ` Al Viro
2024-12-23 21:44     ` James Bottomley
2024-12-10 17:02 ` [PATCH 4/6] efivarfs: move freeing of variable entry into evict_inode James Bottomley
2024-12-11 11:19   ` Christian Brauner
2024-12-10 17:02 ` [PATCH 5/6] efivarfs: remove unused efivarfs_list James Bottomley
2024-12-10 17:02 ` [PATCH 6/6] efivarfs: fix error on write to new variable leaving remnants James Bottomley
2024-12-11 11:16   ` Christian Brauner
2024-12-11 12:39     ` James Bottomley
2024-12-23 19:52       ` James Bottomley
2024-12-23 20:05         ` Al Viro
2024-12-23 21:39           ` James Bottomley
2024-12-23 22:56           ` James Bottomley
2024-12-23 23:12             ` Al Viro
2024-12-24  4:04               ` James Bottomley
2024-12-24  4:44                 ` Al Viro
2024-12-24 13:07                   ` James Bottomley
2024-12-24 15:09                     ` James Bottomley
2024-12-27 14:52                       ` James Bottomley
2024-12-19 17:14   ` James Bottomley
2024-12-22 10:12     ` Christian Brauner
2024-12-23 19:44       ` James Bottomley

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=cbb9303498007cc78ef80f84cbf029e4f84a9b96.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=ardb@kernel.org \
    --cc=dionnaglaze@google.com \
    --cc=jk@ozlabs.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /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