summaryrefslogtreecommitdiffstats
path: root/drivers/firmware
AgeCommit message (Collapse)AuthorFilesLines
2013-02-12efivarfs: guid part of filenames are case-insensitiveMatt Fleming1-2/+93
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: Lingzhu 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: Matt Fleming <matt.fleming@intel.com>
2013-02-12efivarfs: Validate filenames much more aggressivelyMatt Fleming1-5/+44
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: Lingzhu 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: Matt Fleming <matt.fleming@intel.com>
2013-01-31efivarfs: Use sizeof() instead of magic numberMatt Fleming1-1/+1
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: Lingzhu Xiang <lxiang@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-01-31Merge branch 'x86-efi-for-linus' of ↵Linus Torvalds1-2/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 EFI fixes from Peter Anvin: "This is a collection of fixes for the EFI support. The controversial bit here is a set of patches which bumps the boot protocol version as part of fixing some serious problems with the EFI handover protocol, used when booting under EFI using a bootloader as opposed to directly from EFI. These changes should also make it a lot saner to support cross-mode 32/64-bit EFI booting in the future. Getting these changes into 3.8 means we avoid presenting an inconsistent ABI to bootloaders. Other changes are display detection and fixing efivarfs." * 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, efi: remove attribute check from setup_efi_pci x86, build: Dynamically find entry points in compressed startup code x86, efi: Fix PCI ROM handing in EFI boot stub, in 32-bit mode x86, efi: Fix 32-bit EFI handover protocol entry point x86, efi: Fix display detection in EFI boot stub x86, boot: Define the 2.12 bzImage boot protocol x86/boot: Fix minor fd leakage in tools/relocs.c x86, efi: Set runtime_version to the EFI spec revision x86, efi: fix 32-bit warnings in setup_efi_pci() efivarfs: Delete dentry from dcache in efivarfs_file_write() efivarfs: Never return ENOENT from firmware efi, x86: Pass a proper identity mapping in efi_call_phys_prelog efivarfs: Drop link count of the right inode
2013-01-30efi: Make 'efi_enabled' a function to query EFI facilitiesMatt Fleming3-4/+4
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: Matt Fleming <matt.fleming@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-01-18efivarfs: Delete dentry from dcache in efivarfs_file_write()Matt Fleming1-0/+1
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: Jeremy Kerr <jeremy.kerr@canonical.com> Cc: Lee, Chun-Yi <jlee@suse.com> Cc: Andy Whitcroft <apw@canonical.com> Reported-by: Lingzhu Xiang <lxiang@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-01-18efivarfs: Never return ENOENT from firmwareMatt Fleming1-1/+1
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: Jeremy Kerr <jeremy.kerr@canonical.com> Cc: Lee, Chun-Yi <jlee@suse.com> Cc: Andy Whitcroft <apw@canonical.com> Reported-by: Lingzhu Xiang <lxiang@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-01-18efivarfs: Drop link count of the right inodeLingzhu Xiang1-1/+1
efivarfs_unlink() should drop the file's link count, not the directory's. Signed-off-by: Lingzhu Xiang <lxiang@redhat.com> Cc: Jeremy Kerr <jeremy.kerr@canonical.com> Tested-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-01-11efi_pstore: Avoid deadlock in non-blocking pathsSeiji Aguchi1-1/+10
[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: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2013-01-03Drivers: misc: remove __dev* attributes.Greg Kroah-Hartman1-3/+3
CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit from these drivers. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-20drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it existsZhenzhong Duan1-15/+47
The right dmi version is in SMBIOS if it's zero in DMI region This issue was originally found from an oracle bug. One customer noticed system UUID doesn't match between dmidecode & uek2. - HP ProLiant BL460c G6 : # cat /sys/devices/virtual/dmi/id/product_uuid 00000000-0000-4C48-3031-4D5030333531 # dmidecode | grep -i uuid UUID: 00000000-0000-484C-3031-4D5030333531 From SMBIOS 2.6 on, spec use little-endian encoding for UUID other than network byte order. So we need to get dmi version to distinguish. If version is 0.0, the real version is taken from the SMBIOS version. This is part of original kernel comment in code. [akpm@linux-foundation.org: checkpatch fixes] Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com> Cc: Feng Jin <joe.jin@oracle.com> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-12-20drivers/firmware/dmi_scan.c: check dmi version when get system uuidZhenzhong Duan1-3/+15
As of version 2.6 of the SMBIOS specification, the first 3 fields of the UUID are supposed to be little-endian encoded. Also a minor fix to match variable meaning and mute checkpatch.pl [akpm@linux-foundation.org: tweak code comment] Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com> Cc: Feng Jin <joe.jin@oracle.com> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-12-17efi: Fix the build with user namespaces enabled.Eric W. Biederman1-1/+0
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: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-12-14Merge branch 'core-efi-for-linus' of ↵Linus Torvalds1-8/+504
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 EFI update from Peter Anvin: "EFI tree, from Matt Fleming. Most of the patches are the new efivarfs filesystem by Matt Garrett & co. The balance are support for EFI wallclock in the absence of a hardware-specific driver, and various fixes and cleanups." * 'core-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (24 commits) efivarfs: Make efivarfs_fill_super() static x86, efi: Check table header length in efi_bgrt_init() efivarfs: Use query_variable_info() to limit kmalloc() efivarfs: Fix return value of efivarfs_file_write() efivarfs: Return a consistent error when efivarfs_get_inode() fails efivarfs: Make 'datasize' unsigned long efivarfs: Add unique magic number efivarfs: Replace magic number with sizeof(attributes) efivarfs: Return an error if we fail to read a variable efi: Clarify GUID length calculations efivarfs: Implement exclusive access for {get,set}_variable efivarfs: efivarfs_fill_super() ensure we clean up correctly on error efivarfs: efivarfs_fill_super() ensure we free our temporary name efivarfs: efivarfs_fill_super() fix inode reference counts efivarfs: efivarfs_create() ensure we drop our reference on inode on error efivarfs: efivarfs_file_read ensure we free data in error paths x86-64/efi: Use EFI to deal with platform wall clock (again) x86/kernel: remove tboot 1:1 page table creation code x86, efi: 1:1 pagetable mapping for virtual EFI calls x86, mm: Include the entire kernel memory map in trampoline_pgd ...
2012-11-26efi_pstore: Add a format check for an existing variable name at erasing timeSeiji Aguchi1-2/+18
[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: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2012-11-26efi_pstore: Add a format check for an existing variable name at reading timeSeiji Aguchi1-10/+28
[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: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2012-11-26efi_pstore: Add a sequence counter to a variable nameSeiji Aguchi1-9/+14
[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: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2012-11-26efi_pstore: Add ctime to argument of erase callbackSeiji Aguchi1-9/+8
[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: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2012-11-26efi_pstore: Remove a logic erasing entries from a write callback to hold ↵Seiji Aguchi1-37/+2
multiple logs [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: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2012-11-26efi_pstore: Add a logic erasing entries to an erase callbackSeiji Aguchi1-1/+45
[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: Seiji Aguchi <seiji.aguchi@hds.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2012-11-26efi_pstore: Check remaining space with QueryVariableInfo() before writing dataSeiji Aguchi1-0/+18
[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 <seiji.aguchi@hds.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2012-11-15efivarfs: Make efivarfs_fill_super() staticMatt Fleming1-1/+1
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: Matt Fleming <matt.fleming@intel.com>
2012-11-13efivarfs: Use query_variable_info() to limit kmalloc()Matt Fleming1-9/+34
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: Jeremy Kerr <jeremy.kerr@canonical.com> Cc: Matthew Garrett <mjg@redhat.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: Fix return value of efivarfs_file_write()Matt Fleming1-5/+8
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: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: Return a consistent error when efivarfs_get_inode() failsMatt Fleming1-1/+1
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: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: Make 'datasize' unsigned longMatt Fleming1-1/+1
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: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: Add unique magic numberMatt Fleming1-1/+1
Using pstore's superblock magic number is no doubt going to cause problems in the future. Give efivarfs its own magic number. Acked-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: Replace magic number with sizeof(attributes)Matt Fleming1-4/+4
Seeing "+ 4" littered throughout the functions gets a bit confusing. Use "sizeof(attributes)" which clearly explains what quantity we're adding. Acked-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: Return an error if we fail to read a variableMatt Fleming1-26/+36
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: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efi: Clarify GUID length calculationsJeremy Kerr1-8/+25
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: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: Implement exclusive access for {get,set}_variableJeremy Kerr1-25/+43
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: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: efivarfs_fill_super() ensure we clean up correctly on errorAndy Whitcroft1-2/+18
Ensure we free both the name and inode on error when building the individual variables. Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: efivarfs_fill_super() ensure we free our temporary nameAndy Whitcroft1-0/+2
d_alloc_name() copies the passed name to new storage, once complete we no longer need our name. Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: efivarfs_fill_super() fix inode reference countsAndy Whitcroft1-12/+4
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: Andy Whitcroft <apw@canonical.com> Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: efivarfs_create() ensure we drop our reference on inode on errorAndy Whitcroft1-5/+9
Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efivarfs: efivarfs_file_read ensure we free data in error pathsAndy Whitcroft1-3/+3
Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efi: add efivars kobject to efi sysfs folderLee, Chun-Yi1-0/+9
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: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efi: Handle deletions and size changes in efivarfs_write_fileJeremy Kerr1-10/+39
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: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-30efi: Add support for a UEFI variable filesystemMatthew Garrett1-6/+378
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: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2012-10-19firmware/memmap: avoid type conflicts with the generic memmap_init()Fengguang Wu1-2/+2
Fix this build error: drivers/firmware/memmap.c:240:19: error: conflicting types for 'memmap_init' arch/ia64/include/asm/pgtable.h:565:17: note: previous declaration of 'memmap_init' was here Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Cc: Bernhard Walle <bwalle@suse.de> Cc: Glauber Costa <glommer@parallels.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-09-10firmware: Add missing attributes to EFI variable attribute print out from sysfsKhalid Aziz1-3/+14
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: Khalid Aziz <khalid.aziz@hp.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Matthew Garrett <mjg@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-31Merge tag 'random_for_linus' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random Pull random subsystem patches from Ted Ts'o: "This patch series contains a major revamp of how we collect entropy from interrupts for /dev/random and /dev/urandom. The goal is to addresses weaknesses discussed in the paper "Mining your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", by Nadia Heninger, Zakir Durumeric, Eric Wustrow, J. Alex Halderman, which will be published in the Proceedings of the 21st Usenix Security Symposium, August 2012. (See https://factorable.net for more information and an extended version of the paper.)" Fix up trivial conflicts due to nearby changes in drivers/{mfd/ab3100-core.c, usb/gadget/omap_udc.c} * tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random: (33 commits) random: mix in architectural randomness in extract_buf() dmi: Feed DMI table to /dev/random driver random: Add comment to random_initialize() random: final removal of IRQF_SAMPLE_RANDOM um: remove IRQF_SAMPLE_RANDOM which is now a no-op sparc/ldc: remove IRQF_SAMPLE_RANDOM which is now a no-op [ARM] pxa: remove IRQF_SAMPLE_RANDOM which is now a no-op board-palmz71: remove IRQF_SAMPLE_RANDOM which is now a no-op isp1301_omap: remove IRQF_SAMPLE_RANDOM which is now a no-op pxa25x_udc: remove IRQF_SAMPLE_RANDOM which is now a no-op omap_udc: remove IRQF_SAMPLE_RANDOM which is now a no-op goku_udc: remove IRQF_SAMPLE_RANDOM which was commented out uartlite: remove IRQF_SAMPLE_RANDOM which is now a no-op drivers: hv: remove IRQF_SAMPLE_RANDOM which is now a no-op xen-blkfront: remove IRQF_SAMPLE_RANDOM which is now a no-op n2_crypto: remove IRQF_SAMPLE_RANDOM which is now a no-op pda_power: remove IRQF_SAMPLE_RANDOM which is now a no-op i2c-pmcmsp: remove IRQF_SAMPLE_RANDOM which is now a no-op input/serio/hp_sdc.c: remove IRQF_SAMPLE_RANDOM which is now a no-op mfd: remove IRQF_SAMPLE_RANDOM which is now a no-op ...
2012-07-30firmware_map: make firmware_map_add_early() argument consistent with ↵Yasuaki Ishimatsu1-4/+4
firmware_map_add_hotplug() There are two ways to create /sys/firmware/memmap/X sysfs: - firmware_map_add_early When the system starts, it is calledd from e820_reserve_resources() - firmware_map_add_hotplug When the memory is hot plugged, it is called from add_memory() But these functions are called without unifying value of end argument as below: - end argument of firmware_map_add_early() : start + size - 1 - end argument of firmware_map_add_hogplug() : start + size The patch unifies them to "start + size". Even if applying the patch, /sys/firmware/memmap/X/end file content does not change. [akpm@linux-foundation.org: clarify comments] Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by: Dave Hansen <dave@linux.vnet.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-07-30pcdp: use early_ioremap/early_iounmap to access pcdp tableGreg Pearson1-2/+2
efi_setup_pcdp_console() is called during boot to parse the HCDP/PCDP EFI system table and setup an early console for printk output. The routine uses ioremap/iounmap to setup access to the HCDP/PCDP table information. The call to ioremap is happening early in the boot process which leads to a panic on x86_64 systems: panic+0x01ca do_exit+0x043c oops_end+0x00a7 no_context+0x0119 __bad_area_nosemaphore+0x0138 bad_area_nosemaphore+0x000e do_page_fault+0x0321 page_fault+0x0020 reserve_memtype+0x02a1 __ioremap_caller+0x0123 ioremap_nocache+0x0012 efi_setup_pcdp_console+0x002b setup_arch+0x03a9 start_kernel+0x00d4 x86_64_start_reservations+0x012c x86_64_start_kernel+0x00fe This replaces the calls to ioremap/iounmap in efi_setup_pcdp_console() with calls to early_ioremap/early_iounmap which can be called during early boot. This patch was tested on an x86_64 prototype system which uses the HCDP/PCDP table for early console setup. Signed-off-by: Greg Pearson <greg.pearson@hp.com> Acked-by: Khalid Aziz <khalid.aziz@hp.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-07-24dmi: Feed DMI table to /dev/random driverTony Luck1-0/+3
Send the entire DMI (SMBIOS) table to the /dev/random driver to help seed its pools. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2012-05-03efivars: Improve variable validationMatthew Garrett1-16/+30
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: Matthew Garrett <mjg@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-30efi: Validate UEFI boot variablesMatthew Garrett1-0/+182
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: Matthew Garrett <mjg@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-01-12Merge branch 'for-linus' of ↵Linus Torvalds3-166/+0
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (526 commits) ASoC: twl6040 - Add method to query optimum PDM_DL1 gain ALSA: hda - Fix the lost power-setup of seconary pins after PM resume ALSA: usb-audio: add Yamaha MOX6/MOX8 support ALSA: virtuoso: add S/PDIF input support for all Xonars ALSA: ice1724 - Support for ooAoo SQ210a ALSA: ice1724 - Allow card info based on model only ALSA: ice1724 - Create capture pcm only for ADC-enabled configurations ALSA: hdspm - Provide unique driver id based on card serial ASoC: Dynamically allocate the rtd device for a non-empty release() ASoC: Fix recursive dependency due to select ATMEL_SSC in SND_ATMEL_SOC_SSC ALSA: hda - Fix the detection of "Loopback Mixing" control for VIA codecs ALSA: hda - Return the error from get_wcaps_type() for invalid NIDs ALSA: hda - Use auto-parser for HP laptops with cx20459 codec ALSA: asihpi - Fix potential Oops in snd_asihpi_cmode_info() ALSA: hdsp - Fix potential Oops in snd_hdsp_info_pref_sync_ref() ALSA: hda/cirrus - support for iMac12,2 model ASoC: cx20442: add bias control over a platform provided regulator ALSA: usb-audio - Avoid flood of frame-active debug messages ALSA: snd-usb-us122l: Delete calls to preempt_disable mfd: Put WM8994 into cache only mode when suspending ... Fix up trivial conflicts in: - arch/arm/mach-s3c64xx/mach-crag6410.c: renamed speyside_wm8962 to tobermory, added littlemill right next to it - drivers/base/regmap/{regcache.c,regmap.c}: duplicate diff that had already come in with other changes in the regmap tree
2012-01-08Merge branch 'for-linus2' of ↵Linus Torvalds1-6/+6
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs * 'for-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (165 commits) reiserfs: Properly display mount options in /proc/mounts vfs: prevent remount read-only if pending removes vfs: count unlinked inodes vfs: protect remounting superblock read-only vfs: keep list of mounts for each superblock vfs: switch ->show_options() to struct dentry * vfs: switch ->show_path() to struct dentry * vfs: switch ->show_devname() to struct dentry * vfs: switch ->show_stats to struct dentry * switch security_path_chmod() to struct path * vfs: prefer ->dentry->d_sb to ->mnt->mnt_sb vfs: trim includes a bit switch mnt_namespace ->root to struct mount vfs: take /proc/*/mounts and friends to fs/proc_namespace.c vfs: opencode mntget() mnt_set_mountpoint() vfs: spread struct mount - remaining argument of next_mnt() vfs: move fsnotify junk to struct mount vfs: move mnt_devname vfs: move mnt_list to struct mount vfs: switch pnode.h macros to struct mount * ...
2012-01-07Merge branch 'driver-core-next' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core * 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (73 commits) arm: fix up some samsung merge sysdev conversion problems firmware: Fix an oops on reading fw_priv->fw in sysfs loading file Drivers:hv: Fix a bug in vmbus_driver_unregister() driver core: remove __must_check from device_create_file debugfs: add missing #ifdef HAS_IOMEM arm: time.h: remove device.h #include driver-core: remove sysdev.h usage. clockevents: remove sysdev.h arm: convert sysdev_class to a regular subsystem arm: leds: convert sysdev_class to a regular subsystem kobject: remove kset_find_obj_hinted() m86k: gpio - convert sysdev_class to a regular subsystem mips: txx9_sram - convert sysdev_class to a regular subsystem mips: 7segled - convert sysdev_class to a regular subsystem sh: dma - convert sysdev_class to a regular subsystem sh: intc - convert sysdev_class to a regular subsystem power: suspend - convert sysdev_class to a regular subsystem power: qe_ic - convert sysdev_class to a regular subsystem power: cmm - convert sysdev_class to a regular subsystem s390: time - convert sysdev_class to a regular subsystem ... Fix up conflicts with 'struct sysdev' removal from various platform drivers that got changed: - arch/arm/mach-exynos/cpu.c - arch/arm/mach-exynos/irq-eint.c - arch/arm/mach-s3c64xx/common.c - arch/arm/mach-s3c64xx/cpu.c - arch/arm/mach-s5p64x0/cpu.c - arch/arm/mach-s5pv210/common.c - arch/arm/plat-samsung/include/plat/cpu.h - arch/powerpc/kernel/sysfs.c and fix up cpu_is_hotpluggable() as per Greg in include/linux/cpu.h
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-13 02:03:08 +0000