All of lore.kernel.org
 help / color / mirror / Atom feed
From: joeyli <jlee@suse.com>
To: Vladis Dronov <vdronov@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] efi: fix a race and a buffer overflow while reading efivars via sysfs
Date: Wed, 4 Mar 2020 14:51:22 +0800	[thread overview]
Message-ID: <20200304065122.GK16878@linux-l9pv.suse> (raw)
In-Reply-To: <358842423.12639861.1583231098544.JavaMail.zimbra@redhat.com>

Hi all,

On Tue, Mar 03, 2020 at 05:24:58AM -0500, Vladis Dronov wrote:
> Hello, Ard, all,
> 
> > > Wouldn't it be easier to pass a var_data_size stack variable into
> > > efivar_entry_get(), and only update the value in 'var' if it is <=
> > > 1024?
> > > 
> > 
> > I was thinking about this approach, but this way we still do not protect
> > var from a concurrent access. For example, efivar_data_read() can race
> > with itself:
> 
> Oh, indeed, this race is not possible the way you sugget with a var_data_size
> stack variable. Unfortunately, AFAIU, the read/write race stays:
>  
> > ... efivar read functions still can race with the write function
> > efivar_store_raw(). Surely, the race window is much smaller but it is there.
> > I strongly believe we need to protect all data accesses here with a lock.
>

Looks that kernel uses EFI protocol to query variable everytime, then
why should kernel keeps a copy of variable data size, data and attributes in
memory? It makes sense to keep VariableName and VendorGuid, but why data?

The efi_variable can be used to interactive with userland. But we do not
need to keep a data copy in efi_variable with efivar_entry. e.g. The
efivarfs_file_read() allocates a buffer for reading variable instead
of using efi_variable->Data. 

Regards
Joey Lee

  reply	other threads:[~2020-03-04  6:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03  8:55 [PATCH] efi: fix a race and a buffer overflow while reading efivars via sysfs Vladis Dronov
2020-03-03  9:15 ` Ard Biesheuvel
2020-03-03 10:14   ` Vladis Dronov
2020-03-03 10:20     ` Ard Biesheuvel
2020-03-03 10:24     ` Vladis Dronov
2020-03-04  6:51       ` joeyli [this message]
2020-03-04 15:45   ` Vladis Dronov
2020-03-04 15:47     ` Ard Biesheuvel
2020-03-04 15:49   ` [PATCH v2] " Vladis Dronov
2020-03-04 15:57     ` Ard Biesheuvel
2020-03-04 17:18       ` Vladis Dronov
2020-03-04 17:21         ` Ard Biesheuvel
2020-03-05  6:01     ` joeyli
2020-03-05  6:17       ` Vladis Dronov
2020-03-05  8:40   ` [PATCH v3 0/3] efi: fix a race and add a sanity check Vladis Dronov
2020-03-05  8:40     ` [PATCH v3 1/3] efi: fix a race and a buffer overflow while reading efivars via sysfs Vladis Dronov
2020-03-05  8:45       ` Ard Biesheuvel
2020-03-05 10:52         ` Vladis Dronov
2020-03-08 16:38       ` [tip: efi/urgent] efi: Fix " tip-bot2 for Vladis Dronov
2020-03-05  8:40     ` [PATCH v3 2/3] efi: add a sanity check to efivar_store_raw() Vladis Dronov
2020-03-08 16:38       ` [tip: efi/urgent] efi: Add " tip-bot2 for Vladis Dronov
2020-03-09 12:25         ` Sasha Levin
2020-03-09 12:38           ` Vladis Dronov
2020-03-16 14:21           ` Vladis Dronov
2020-03-05  8:40     ` [PATCH v3 3/3] efi: fix a mistype in comments mentioning efivar_entry_iter_begin() Vladis Dronov
2020-03-05  8:51     ` [PATCH v3 0/3] efi: fix a race and add a sanity check Ard Biesheuvel
2020-03-04 14:07 ` [PATCH] efi: fix a race and a buffer overflow while reading efivars via sysfs joeyli
2020-03-04 16:06   ` Vladis Dronov

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=20200304065122.GK16878@linux-l9pv.suse \
    --to=jlee@suse.com \
    --cc=ardb@kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vdronov@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.