linux-stable.git/include/linux/efi.h, branch v3.2.42

efi_pstore: Introducing workqueue updating sysfs

2013-03-27T02:41:20+00:00

commit a93bc0c6e07ed9bac44700280e65e2945d864fd4 upstream.

[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: Seiji Aguchi 
Acked-by: Matt Fleming 
Signed-off-by: Tony Luck 
[bwh: Backported to 3.2:
 - Adjust contest
 - Don't check reason in efi_pstore_write(), as it is not given as a
   parameter
 - Move up declaration of __efivars]
Signed-off-by: Ben Hutchings

efi: be more paranoid about available space when creating variables

2013-03-20T15:03:28+00:00

commit 68d929862e29a8b52a7f2f2f86a0600423b093cd upstream.

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: Matthew Garrett 
Signed-off-by: Matt Fleming 
[bwh: Backported to 3.2:
 - Drop efivarfs changes and unused check_var_size()
 - Add error codes to include/linux/efi.h, added upstream by
   commit 5d9db883761a ('efi: Add support for a UEFI variable filesystem')
 - Add efi_status_to_err(), added upstream by commit 7253eaba7b17
   ('efivarfs: Return an error if we fail to read a variable')]
Signed-off-by: Ben Hutchings

efi_pstore: Check remaining space with QueryVariableInfo() before writing data

2013-03-20T15:03:27+00:00

commit d80a361d779a9f19498943d1ca84243209cd5647 upstream.

[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: Seiji Aguchi 
Acked-by: Mike Waychison 
Signed-off-by: Tony Luck 
Signed-off-by: Ben Hutchings

efi: Make 'efi_enabled' a function to query EFI facilities

2013-02-06T04:33:50+00:00

commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream.

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 
Cc: Corentin Chary 
Cc: Matthew Garrett 
Cc: Dave Jiang 
Cc: Olof Johansson 
Cc: Peter Jones 
Cc: Colin Ian King 
Cc: Steve Langasek 
Cc: Tony Luck 
Cc: Konrad Rzeszutek Wilk 
Cc: Rafael J. Wysocki 
Signed-off-by: Matt Fleming 
Signed-off-by: H. Peter Anvin 
[bwh: Backported to 3.2:
 - Adjust context (a lot)
 - Add efi_is_native() function from commit 5189c2a7c776
   ('x86: efi: Turn off efi_enabled after setup on mixed fw/kernel')
 - Make efi_init() bail out when booted non-native, as it would previously
   not be called in this case
 - Drop inapplicable changes to start_kernel()]
Signed-off-by: Ben Hutchings

efi: Add new variable attributes

2012-05-11T12:14:47+00:00

commit 41b3254c93acc56adc3c4477fef7c9512d47659e upstream.

More recent versions of the UEFI spec have added new attributes for
variables. Add them.

Signed-off-by: Matthew Garrett 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

Merge branch 'pstore-efi' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6

2011-08-01T23:40:51+00:00

* 'pstore-efi' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6:
  efivars: Introduce PSTORE_EFI_ATTRIBUTES
  efivars: Use string functions in pstore_write
  efivars: introduce utf16_strncmp
  efivars: String functions
  efi: Add support for using efivars as a pstore backend
  pstore: Allow the user to explicitly choose a backend
  pstore: Make "part" unsigned
  pstore: Add extra context for writes and erases
  pstore: Extend API for more flexibility in new backends

efi: Add support for using efivars as a pstore backend

2011-07-22T23:15:04+00:00

EFI provides an area of nonvolatile storage managed by the firmware. We
can use this as a pstore backend to maintain copies of oopses, aiding
diagnosis.

Signed-off-by: Matthew Garrett 
Signed-off-by: Tony Luck

x86, efi: Add infrastructure for UEFI 2.0 runtime services

2011-06-06T20:30:30+00:00

We're currently missing support for any of the runtime service calls
introduced with the UEFI 2.0 spec in 2006. Add the infrastructure for
supporting them.

Signed-off-by: Matthew Garrett 
Link: http://lkml.kernel.org/r/1307388985-7852-2-git-send-email-mjg@redhat.com
Signed-off-by: H. Peter Anvin

x86, efi: Fix argument types for SetVariable()

2011-06-06T20:30:27+00:00

The spec says this takes uint32 for attributes, not uintn.

Signed-off-by: Matthew Garrett 
Link: http://lkml.kernel.org/r/1307388985-7852-1-git-send-email-mjg@redhat.com
Signed-off-by: H. Peter Anvin

x86, efi: Retain boot service code until after switching to virtual mode

2011-05-26T00:03:53+00:00

UEFI stands for "Unified Extensible Firmware Interface", where "Firmware"
is an ancient African word meaning "Why do something right when you can
do it so wrong that children will weep and brave adults will cower before
you", and "UEI" is Celtic for "We missed DOS so we burned it into your
ROMs". The UEFI specification provides for runtime services (ie, another
way for the operating system to be forced to depend on the firmware) and
we rely on these for certain trivial tasks such as setting up the
bootloader. But some hardware fails to work if we attempt to use these
runtime services from physical mode, and so we have to switch into virtual
mode. So far so dreadful.

The specification makes it clear that the operating system is free to do
whatever it wants with boot services code after ExitBootServices() has been
called. SetVirtualAddressMap() can't be called until ExitBootServices() has
been. So, obviously, a whole bunch of EFI implementations call into boot
services code when we do that. Since we've been charmingly naive and
trusted that the specification may be somehow relevant to the real world,
we've already stuffed a picture of a penguin or something in that address
space. And just to make things more entertaining, we've also marked it
non-executable.

This patch allocates the boot services regions during EFI init and makes
sure that they're executable. Then, after SetVirtualAddressMap(), it
discards them and everyone lives happily ever after. Except for the ones
who have to work on EFI, who live sad lives haunted by the knowledge that
someone's eventually going to write yet another firmware specification.

[ hpa: adding this to urgent with a stable tag since it fixes currently-broken
  hardware.  However, I do not know what the dependencies are and so I do
  not know which -stable versions this may be a candidate for. ]

Signed-off-by: Matthew Garrett 
Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.com
Signed-off-by: H. Peter Anvin 
Cc: Tony Luck 
Cc: