UEFI variables are typically stored in flash. For various reasons, avaiable
space is typically not reclaimed immediately upon the deletion of a
variable - instead, the system will garbage collect during initialisation
after a reboot.

Some systems appear to handle this garbage collection extremely poorly,
failing if more than 50% of the system flash is in use. This can result in
the machine refusing to boot. The safest thing to do for the moment is to
forbid writes if they'd end up using more than half of the storage space.
We can make this more finegrained later if we come up with a method for
identifying the broken machines.
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

[Problem]
efi_pstore creates sysfs entries, which enable users to access to NVRAM,
in a write callback. If a kernel panic happens in an interrupt context,
it may fail because it could sleep due to dynamic memory allocations during
creating sysfs entries.

[Patch Description]
This patch removes sysfs operations from a write callback by introducing
a workqueue updating sysfs entries which is scheduled after the write
callback is called.

Also, the workqueue is kicked in a just oops case.
A system will go down in other cases such as panic, clean shutdown and emergency
restart. And we don't need to create sysfs entries because there is no chance for
users to access to them.

efi_pstore will be robust against a kernel panic in an interrupt context with this patch.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NMatt Fleming <matt.fleming@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

[Problem]
There is a scenario which efi_pstore fails to log messages in a panic case.

 - CPUA holds an efi_var->lock in either efivarfs parts
   or efi_pstore with interrupt enabled.
 - CPUB panics and sends IPI to CPUA in smp_send_stop().
 - CPUA stops with holding the lock.
 - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC)
   but it returns without logging messages.

[Patch Description]
This patch disables an external interruption while holding efivars->lock
as follows.

In efi_pstore_write() and get_var_data(), spin_lock/spin_unlock is
replaced by spin_lock_irqsave/spin_unlock_irqrestore because they may
be called in an interrupt context.

In other functions, they are replaced by spin_lock_irq/spin_unlock_irq.
because they are all called from a process context.

By applying this patch, we can avoid the problem above with
a following senario.

 - CPUA holds an efi_var->lock with interrupt disabled.
 - CPUB panics and sends IPI to CPUA in smp_send_stop().
 - CPUA receives the IPI after releasing the lock because it is
   disabling interrupt while holding the lock.
 - CPUB waits for one sec until CPUA releases the lock.
 - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC)
   And it can hold the lock successfully.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NMike Waychison <mikew@google.com>
Acked-by: NMatt Fleming <matt.fleming@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

It makes no sense to treat the following filenames as unique,

	VarName-abcdefab-abcd-abcd-abcd-abcdefabcdef
	VarName-ABCDEFAB-ABCD-ABCD-ABCD-ABCDEFABCDEF
	VarName-ABcDEfAB-ABcD-ABcD-ABcD-ABcDEfABcDEf
	VarName-aBcDEfAB-aBcD-aBcD-aBcD-aBcDEfaBcDEf
	... etc ...

since the guid will be converted into a binary representation, which
has no case.

Roll our own dentry operations so that we can treat the variable name
part of filenames ("VarName" in the above example) as case-sensitive,
but the guid portion as case-insensitive. That way, efivarfs will
refuse to create the above files if any one already exists.
Reported-by: NLingzhu Xiang <lxiang@redhat.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

The only thing that efivarfs does to enforce a valid filename is
ensure that the name isn't too short. We need to strongly sanitise any
filenames, not least because variable creation is delayed until
efivarfs_file_write(), which means we can't rely on the firmware to
inform us of an invalid name, because if the file is never written to
we'll never know it's invalid.

Perform a couple of steps before agreeing to create a new file,

  * hex_to_bin() returns a value indicating whether or not it was able
    to convert its arguments to a binary representation - we should
    check it.

  * Ensure that the GUID portion of the filename is the correct length
    and format.

  * The variable name portion of the filename needs to be at least one
    character in size.
Reported-by: NLingzhu Xiang <lxiang@redhat.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Instead of adding a magic 4 to the variable size, use sizeof() to make
it explicitly clear what the quantity represents (the variable's
attributes).

CC: Jeremy Kerr <jeremy.kerr@canonical.com>
Cc: Chun-Yi Lee <joeyli.kernel@gmail.com>
Cc: Andy Whitcroft <apw@canonical.com>
Reported-by: NLingzhu Xiang <lxiang@redhat.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.

The immediate motivation for this patch is the bug report at,

    https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557

which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,

    https://bugzilla.kernel.org/show_bug.cgi?id=47121

details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,

    if (!efi_enabled)

hasn't been a sufficient condition for quite some time.

Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.

For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).

This patch is a prereq for the samsung-laptop fix patch.

Cc: David Airlie <airlied@linux.ie>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Peter Jones <pjones@redhat.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Steve Langasek <steve.langasek@canonical.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Unlike the unlink path that is called from the VFS layer, we need to
call d_delete() ourselves when a variable is deleted in
efivarfs_file_write().

Failure to do so means we can access a stale struct efivar_entry when
reading/writing the file, which can result in the following oops,

  [   59.978216] general protection fault: 0000 [#1] SMP
  [   60.038660] CPU 9
  [   60.040501] Pid: 1001, comm: cat Not tainted 3.7.0-2.fc19.x86_64 #1 IBM System x3550 M3 -[7944I21]-/69Y4438
  [   60.050840] RIP: 0010:[<ffffffff810d5d1e>]  [<ffffffff810d5d1e>] __lock_acquire+0x5e/0x1bb0
  [   60.059198] RSP: 0018:ffff880270595ce8  EFLAGS: 00010046
  [   60.064500] RAX: 0000000000000046 RBX: 0000000000000002 RCX: 0000000000000000
  [   60.071617] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 6b6b6b6b6b6b6b83
  [   60.078735] RBP: ffff880270595dd8 R08: 0000000000000002 R09: 0000000000000000
  [   60.085852] R10: 6b6b6b6b6b6b6b83 R11: 0000000000000000 R12: 0000000000000000
  [   60.092971] R13: ffff88027170cd20 R14: 0000000000000000 R15: 0000000000000000
  [   60.100091] FS:  00007fc0c8ff3740(0000) GS:ffff880277000000(0000) knlGS:0000000000000000
  [   60.108164] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [   60.113899] CR2: 0000000001520000 CR3: 000000026d594000 CR4: 00000000000007e0
  [   60.121016] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  [   60.128135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  [   60.135254] Process cat (pid: 1001, threadinfo ffff880270594000, task ffff88027170cd20)
  [   60.143239] Stack:
  [   60.145251]  ffff880270595cf8 ffffffff81021da3 ffff880270595d08 ffffffff81021e19
  [   60.152714]  ffff880270595d38 ffffffff810acdb5 ffff880200000168 0000000000000086
  [   60.160175]  ffff88027170d5e8 ffffffff810d25ed ffff880270595d58 ffffffff810ace7f
  [   60.167638] Call Trace:
  [   60.170088]  [<ffffffff81021da3>] ? native_sched_clock+0x13/0x80
  [   60.176085]  [<ffffffff81021e19>] ? sched_clock+0x9/0x10
  [   60.181389]  [<ffffffff810acdb5>] ? sched_clock_cpu+0xc5/0x120
  [   60.187211]  [<ffffffff810d25ed>] ? trace_hardirqs_off+0xd/0x10
  [   60.193121]  [<ffffffff810ace7f>] ? local_clock+0x6f/0x80
  [   60.198513]  [<ffffffff810d2f6f>] ? lock_release_holdtime.part.26+0xf/0x180
  [   60.205465]  [<ffffffff810d7b57>] ? lock_release_non_nested+0x2e7/0x320
  [   60.212073]  [<ffffffff815638bb>] ? efivarfs_file_write+0x5b/0x280
  [   60.218242]  [<ffffffff810d7f41>] lock_acquire+0xa1/0x1f0
  [   60.223633]  [<ffffffff81563971>] ? efivarfs_file_write+0x111/0x280
  [   60.229892]  [<ffffffff8118b47c>] ? might_fault+0x5c/0xb0
  [   60.235287]  [<ffffffff816f1bf6>] _raw_spin_lock+0x46/0x80
  [   60.240762]  [<ffffffff81563971>] ? efivarfs_file_write+0x111/0x280
  [   60.247018]  [<ffffffff81563971>] efivarfs_file_write+0x111/0x280
  [   60.253103]  [<ffffffff811d307f>] vfs_write+0xaf/0x190
  [   60.258233]  [<ffffffff811d33d5>] sys_write+0x55/0xa0
  [   60.263278]  [<ffffffff816fbd19>] system_call_fastpath+0x16/0x1b
  [   60.269271] Code: 41 0f 45 d8 4c 89 75 f0 4c 89 7d f8 85 c0 0f 84 09 01 00 00 8b 05 a3 f9 ff 00 49 89 fa 41 89 f6 41 89 d3 85 c0 0f 84 12 01 00 00 <49> 8b 02 ba 01 00 00 00 48 3d a0 07 14 82 0f 44 da 41 83 fe 01
  [   60.289431] RIP  [<ffffffff810d5d1e>] __lock_acquire+0x5e/0x1bb0
  [   60.295444]  RSP <ffff880270595ce8>
  [   60.298928] ---[ end trace 1bbfd41a2cf6a0d8 ]---

Cc: Josh Boyer <jwboyer@redhat.com>
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Cc: Lee, Chun-Yi <jlee@suse.com>
Cc: Andy Whitcroft <apw@canonical.com>
Reported-by: NLingzhu Xiang <lxiang@redhat.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Files are created in efivarfs_create() before a corresponding variable
is created in the firmware. This leads to users being able to
read/write to the file without the variable existing in the
firmware. Reading a non-existent variable currently returns -ENOENT,
which is confusing because the file obviously *does* exist.

Convert EFI_NOT_FOUND into -EIO which is the closest thing to "error
while interacting with firmware", and should hopefully indicate to the
caller that the variable is in some uninitialised state.

Cc: Josh Boyer <jwboyer@redhat.com>
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Cc: Lee, Chun-Yi <jlee@suse.com>
Cc: Andy Whitcroft <apw@canonical.com>
Reported-by: NLingzhu Xiang <lxiang@redhat.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

efivarfs_unlink() should drop the file's link count, not the directory's.
Signed-off-by: NLingzhu Xiang <lxiang@redhat.com>
Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
Tested-by: NLee, Chun-Yi <jlee@suse.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

[Issue]

There is a scenario which efi_pstore may hang up:

 - cpuA grabs efivars->lock
 - cpuB panics and calls smp_send_stop
 - smp_send_stop sends IRQ to cpuA
 - after 1 second, cpuB gives up on cpuA and sends an NMI instead
 - cpuA is now in an NMI handler while still holding efivars->lock
 - cpuB is deadlocked

This case may happen if a firmware has a bug and
cpuA is stuck talking with it.

[Solution]

This patch changes a spin_lock to a spin_trylock in non-blocking paths.
and if the spin_lock has already taken by another cpu,
it returns without accessing to a firmware to avoid the deadlock.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NDon Zickus <dzickus@redhat.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

When compiling efivars.c the build fails with:

   CC      drivers/firmware/efivars.o
  drivers/firmware/efivars.c: In function ‘efivarfs_get_inode’:
  drivers/firmware/efivars.c:886:31: error: incompatible types when assigning to type ‘kgid_t’ from type ‘int’
  make[2]: *** [drivers/firmware/efivars.o] Error 1
  make[1]: *** [drivers/firmware/efivars.o] Error 2

Fix the build error by removing the duplicate initialization of i_uid and
i_gid inode_init_always has already initialized them to 0.
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

[Issue]

a format of variable name has been updated to type, id, count and ctime
to support holding multiple logs.

Format of current variable name
  dump-type0-1-2-12345678

  type:0
  id:1
  count:2
  ctime:12345678

On the other hand, if an old variable name before being updated
remains, users can't erase it via /dev/pstore.

Format of old variable name
  dump-type0-1-12345678

  type:0
  id:1
  ctime:12345678

[Solution]

This patch add a format check for the old variable name in a erase callback to make it erasable.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

[Issue]

a format of variable name has been updated to type, id, count and ctime
to support holding multiple logs.

Format of current variable name
  dump-type0-1-2-12345678

  type:0
  id:1
  count:2
  ctime:12345678

On the other hand, if an old variable name before being updated
remains, users can't read it via /dev/pstore.

Format of old variable name
  dump-type0-1-12345678

  type:0
  id:1
  ctime:12345678

[Solution]

This patch add a format check for the old variable name in a read callback
to make it readable.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

[Issue]

Currently, a variable name, which identifies each entry, consists of type, id and ctime.
But if multiple events happens in a short time, a second/third event may fail to log because
efi_pstore can't distinguish each event with current variable name.

[Solution]

A reasonable way to identify all events precisely is introducing a sequence counter to
the variable name.

The sequence counter has already supported in a pstore layer with "oopscount".
So, this patch adds it to a variable name.
Also, it is passed to read/erase callbacks of platform drivers in accordance with
the modification of the variable name.

  <before applying this patch>
 a variable name of first event: dump-type0-1-12345678
 a variable name of second event: dump-type0-1-12345678

  type:0
  id:1
  ctime:12345678

 If multiple events happen in a short time, efi_pstore can't distinguish them because
 variable names are same among them.

  <after applying this patch>

 it can be distinguishable by adding a sequence counter as follows.

 a variable name of first event: dump-type0-1-1-12345678
 a variable name of Second event: dump-type0-1-2-12345678

  type:0
  id:1
  sequence counter: 1(first event), 2(second event)
  ctime:12345678

In case of a write callback executed in pstore_console_write(), "0" is added to
an argument of the write callback because it just logs all kernel messages and
doesn't need to care about multiple events.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

[Issue]

Currently, a variable name, which is used to identify each log entry, consists of type,
id and ctime. But an erase callback does not use ctime.

If efi_pstore supported just one log, type and id were enough.
However, in case of supporting multiple logs, it doesn't work because
it can't distinguish each entry without ctime at erasing time.

 <Example>

 As you can see below, efi_pstore can't differentiate first event from second one without ctime.

 a variable name of first event: dump-type0-1-12345678
 a variable name of second event: dump-type0-1-23456789

  type:0
  id:1
  ctime:12345678, 23456789

[Solution]

This patch adds ctime to an argument of an erase callback.

It works across reboots because ctime of pstore means the date that the record was originally stored.
To do this, efi_pstore saves the ctime to variable name at writing time and passes it to pstore
at reading time.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

[Issue]

Currently, efi_pstore driver simply overwrites existing panic messages in NVRAM.
So, in the following scenario, we will lose 1st panic messages.

1. kernel panics.
2. efi_pstore is kicked and writes panic messages to NVRAM.
3. system reboots.
4. kernel panics again before a user checks the 1st panic messages in NVRAM.

[Solution]

A reasonable solution to fix the issue is just holding multiple logs without erasing
existing entries.
This patch removes a logic erasing existing entries in a write callback
because the logic is not needed in the write callback to support holding multiple logs.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

[Issue]

Currently, efi_pstore driver simply overwrites existing panic messages in NVRAM.
So, in the following scenario, we will lose 1st panic messages.

 1. kernel panics.
 2. efi_pstore is kicked and writes panic messages to NVRAM.
 3. system reboots.
 4. kernel panics again before a user checks the 1st panic messages in NVRAM.

[Solution]

A reasonable solution to fix the issue is just holding multiple logs without erasing
existing entries.

This patch freshly adds a logic erasing existing entries, which shared with a write callback,
to an erase callback.
To support holding multiple logs, the write callback doesn't need to erase any entries and
it will be removed in a subsequent patch.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

[Issue]

As discussed in a thread below, Running out of space in EFI isn't a well-tested scenario.
And we wouldn't expect all firmware to handle it gracefully.
http://marc.info/?l=linux-kernel&m=134305325801789&w=2

On the other hand, current efi_pstore doesn't check a remaining space of storage at writing time.
Therefore, efi_pstore may not work if it tries to write a large amount of data.

[Patch Description]

To avoid handling the situation above, this patch checks if there is a space enough to log with
QueryVariableInfo() before writing data.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Acked-by: NMike Waychison <mikew@google.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

sparse is complaining that efivarfs_fill_super() doesn't have a
prototype. Make it static to avoid the warning.

Cc: Xie ChanglongX <changlongx.xie@intel.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

We don't want someone who can write EFI variables to be able to
allocate arbitrarily large amounts of memory, so cap it to something
sensible like the amount of free space for EFI variables.
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

We're stuffing a variable of type size_t (unsigned) into a ssize_t
(signed) which, even though both types should be the same number of
bits, it's just asking for sign issues to be introduced.

Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
Reported-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Instead of returning -ENOSPC if efivarfs_get_inode() fails we should
be returning -ENOMEM, since running out of memory is the only reason
it can fail.  Furthermore, that's the error value used everywhere else
in this file. It's also less likely to confuse users that hit this
error case.
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

There's no reason to declare 'datasize' as an int, since the majority
of the functions it's passed to expect an unsigned long anyway. Plus,
this way we avoid any sign problems during arithmetic.
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Using pstore's superblock magic number is no doubt going to cause
problems in the future. Give efivarfs its own magic number.
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Seeing "+ 4" littered throughout the functions gets a bit
confusing. Use "sizeof(attributes)" which clearly explains what
quantity we're adding.
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Instead of always returning 0 in efivarfs_file_read(), even when we
fail to successfully read the variable, convert the EFI status to
something meaningful and return that to the caller. This way the user
will have some hint as to why the read failed.
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

At present, the handling of GUIDs in efivar file names isn't consistent.
We use GUID_LEN in some places, and 38 in others (GUID_LEN plus
separator), and implicitly use the presence of the trailing NUL.

This change removes the trailing NUL from GUID_LEN, so that we're
explicitly adding it when required. We also replace magic numbers
with GUID_LEN, and clarify the comments where appropriate.

We also fix the allocation size in efivar_create_sysfs_entry, where
we're allocating one byte too much, due to counting the trailing NUL
twice - once when calculating short_name_size, and once in the kzalloc.
Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Currently, efivarfs does not enforce exclusion over the get_variable and
set_variable operations. Section 7.1 of UEFI requires us to only allow a
single processor to enter {get,set}_variable services at once.

This change acquires the efivars->lock over calls to these operations
from the efivarfs paths.
Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Ensure we free both the name and inode on error when building the
individual variables.
Signed-off-by: NAndy Whitcroft <apw@canonical.com>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

d_alloc_name() copies the passed name to new storage, once complete we
no longer need our name.
Signed-off-by: NAndy Whitcroft <apw@canonical.com>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

When d_make_root() fails it will automatically drop the reference
on the root inode.  We should not be doing so as well.
Signed-off-by: NAndy Whitcroft <apw@canonical.com>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Signed-off-by: NAndy Whitcroft <apw@canonical.com>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Signed-off-by: NAndy Whitcroft <apw@canonical.com>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

UEFI variable filesystem need a new mount point, so this patch add
efivars kobject to efi_kobj for create a /sys/firmware/efi/efivars
folder.

Cc: Matthew Garrett <mjg@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: NLee, Chun-Yi <jlee@suse.com>
Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

A write to an efivarfs file will not always result in a variable of
'count' size after the EFI SetVariable() call. We may have appended to
the existing data (ie, with the EFI_VARIABLE_APPEND_WRITE attribute), or
even have deleted the variable (with an authenticated variable update,
with a zero datasize).

This change re-reads the updated variable from firmware, to check for
size changes and deletions. In the latter case, we need to drop the
dentry.
Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

The existing EFI variables code only supports variables of up to 1024
bytes. This limitation existed in version 0.99 of the EFI specification,
but was removed before any full releases. Since variables can now be
larger than a single page, sysfs isn't the best interface for this. So,
instead, let's add a filesystem. Variables can be read, written and
created, with the first 4 bytes of each variable representing its UEFI
attributes. The create() method doesn't actually commit to flash since
zero-length variables can't exist per-spec.

Updates from Jeremy Kerr <jeremy.kerr@canonical.com>.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Some of the EFI variable attributes are missing from print out from
/sys/firmware/efi/vars/*/attributes. This patch adds those in. It also
updates code to use pre-defined constants for masking current value
of attributes.
Signed-off-by: NKhalid Aziz <khalid.aziz@hp.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Ben Hutchings pointed out that the validation in efivars was inadequate -
most obviously, an entry with size 0 would server as a DoS against the
kernel. Improve this based on his suggestions.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

A common flaw in UEFI systems is a refusal to POST triggered by a malformed
boot variable. Once in this state, machines may only be restored by
reflashing their firmware with an external hardware device. While this is
obviously a firmware bug, the serious nature of the outcome suggests that
operating systems should filter their variable writes in order to prevent
a malicious user from rendering the machine unusable.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>