public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-efi@vger.kernel.org,
	Jeremy Kerr <jk@ozlabs.org>,
	Christian Brauner <brauner@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v2 0/6] convert efivarfs to manage object data correctly
Date: Sat, 18 Jan 2025 08:53:11 -0500	[thread overview]
Message-ID: <1242f7acd71dfdabfd5507b2d439e2380343ca8a.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAMj1kXHy+D2GDANFyYJLOZj1fPmgoX+Ed6CRy3mSSCeutsO07w@mail.gmail.com>

On Thu, 2025-01-09 at 10:50 +0100, Ard Biesheuvel wrote:
> Are there any existing test suites that cover efivarfs that you could
> recommend?

The good news is there is actually an existing test suite.  I was
writing some for selftests/filesystems/efivarfs, but it turns out they
exist in selftests/efivarfs.  You can run them from the kernel source
tree (in a VM with your changes) as:

make -C tools/testing/selftests TARGETS=efivarfs run_tests

So I've merged all the testing I had here and started writing new ones.

The bad news is that writing new tests I've run across another corner
case in the efivarfs code: you can set the inode size to anything you
want (as root) which means you can take a real variable and get it to
mimic an uncommitted one (at least to stat):

# ls -l /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c 
-rw-r--r-- 1 root root 841 Jan 18 13:40 /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
# chattr -i /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
# > /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
# ls -l /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 0 Jan 18 13:40 /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c

I'm not sure how much of a bug this is for the old code (only systemd
seems to check for zero size files), and it's only in the cache inode,
so if you cat the file you get the fully 841 bytes.  However, obviously
it becomes a huge problem with my new code because you can use the
truncate inode to actually delete the variable file (even thought the
variable is still there) so I need to add a fix for it to my series. 
I'll post it separately when I have it to see what you think.

Regards,

James


      parent reply	other threads:[~2025-01-18 13:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-07  2:35 [PATCH v2 0/6] convert efivarfs to manage object data correctly James Bottomley
2025-01-07  2:35 ` [PATCH v2 1/6] efivarfs: remove unused efi_varaible.Attributes and .kobj James Bottomley
2025-01-07  2:35 ` [PATCH v2 2/6] efivarfs: add helper to convert from UC16 name and GUID to utf8 name James Bottomley
2025-01-07  2:35 ` [PATCH v2 3/6] efivarfs: make variable_is_present use dcache lookup James Bottomley
2025-01-07  2:35 ` [PATCH v2 4/6] efivarfs: move freeing of variable entry into evict_inode James Bottomley
2025-01-16 18:36   ` Al Viro
2025-01-16 19:05     ` James Bottomley
2025-01-16 22:13       ` James Bottomley
2025-01-19 14:50         ` Ard Biesheuvel
2025-01-19 14:57           ` James Bottomley
2025-01-19 16:31             ` Ard Biesheuvel
2025-01-19 16:46               ` James Bottomley
2025-01-07  2:35 ` [PATCH v2 5/6] efivarfs: remove unused efivarfs_list James Bottomley
2025-01-16 18:42   ` Al Viro
2025-01-16 18:55     ` James Bottomley
2025-01-07  2:35 ` [PATCH v2 6/6] efivarfs: fix error on write to new variable leaving remnants James Bottomley
2025-01-16 18:45   ` Al Viro
2025-01-16 18:54     ` James Bottomley
2025-01-16 18:59       ` Al Viro
2025-01-16 19:04         ` James Bottomley
2025-01-09  9:50 ` [PATCH v2 0/6] convert efivarfs to manage object data correctly Ard Biesheuvel
2025-01-09 14:24   ` Ard Biesheuvel
2025-01-09 15:50   ` James Bottomley
2025-01-09 16:11     ` Ard Biesheuvel
2025-01-18 13:53   ` James Bottomley [this message]

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=1242f7acd71dfdabfd5507b2d439e2380343ca8a.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=ardb@kernel.org \
    --cc=brauner@kernel.org \
    --cc=jk@ozlabs.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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