16 Jul, 2020
1 commit
-
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.Signed-off-by: Alexander A. Klimov
Signed-off-by: Jean Delvare
06 Jun, 2020
1 commit
-
Some vendors like HPe or Dell, encode the release version of their BIOS
in the "System BIOS {Major|Minor} Release" fields of Type 0.This information is used to know which bios release actually runs.
It could be used for some quirks, debugging sessions or inventory tasks.A typical output for a Dell system running the 65.27 bios is :
[root@t1700 ~]# cat /sys/devices/virtual/dmi/id/bios_release
65.27
[root@t1700 ~]#Servers that have a BMC encode the release version of their firmware in the
"Embedded Controller Firmware {Major|Minor} Release" fields of Type 0.This information is used to know which BMC release actually runs.
It could be used for some quirks, debugging sessions or inventory tasks.A typical output for a Dell system running the 3.75 bmc release is :
[root@t1700 ~]# cat /sys/devices/virtual/dmi/id/ec_firmware_release
3.75
[root@t1700 ~]#Signed-off-by: Erwan Velu
Signed-off-by: Jean Delvare
23 Mar, 2020
1 commit
-
Use SMBIOS_ENTRY_POINT_SCAN_START instead of 0xF0000, because other
archtecture maybe use a special start address such as 0xFFFE000 for
Loongson platform.Signed-off-by: Tiezhu Yang
Reviewed-by: Jean Delvare
Signed-off-by: Thomas Bogendoerfer
03 Dec, 2019
2 commits
-
Add a utility function dmi_memdev_handle() which returns the DMI
handle associated with a given memory slot. This will allow kernel
drivers to iterate over the memory slots.Signed-off-by: Jean Delvare
-
Store the memory type while walking the memory slots, and provide a
way to retrieve it later.Signed-off-by: Jean Delvare
15 Oct, 2019
1 commit
-
Before reading the Extended Size field, we should ensure it fits in
the DMI record. There is already a record length check but it does
not cover that field.It would take a seriously corrupted DMI table to hit that bug, so no
need to worry, but we should still fix it.Signed-off-by: Jean Delvare
Fixes: 6deae96b42eb ("firmware, DMI: Add function to look up a handle and return DIMM size")
Cc: Tony Luck
Cc: Borislav Petkov
21 May, 2019
1 commit
-
Add SPDX license identifiers to all files which:
- Have no license information of any form
- Have EXPORT_.*_SYMBOL_GPL inside which was used in the
initial scan/conversion to ignore the fileThese files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:GPL-2.0-only
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
29 Mar, 2019
1 commit
-
All architectures (arm/arm64, ia64 and x86) do the same here, so unify
the code.Note: We do not need to call dump_stack_set_arch_desc() in case of
!dmi_available. Both strings, dmi_ids_string and dump_stack_arch_
desc_str are initialized zero and thus nothing would change.Signed-off-by: Robert Richter
Signed-off-by: Ard Biesheuvel
Reviewed-by: Jean Delvare
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190328193429.21373-5-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar
31 Oct, 2018
1 commit
-
Move remaining definitions and declarations from include/linux/bootmem.h
into include/linux/memblock.h and remove the redundant header.The includes were replaced with the semantic patch below and then
semi-automated removal of duplicated '#include@@
@@
- #include
+ #include[sfr@canb.auug.org.au: dma-direct: fix up for the removal of linux/bootmem.h]
Link: http://lkml.kernel.org/r/20181002185342.133d1680@canb.auug.org.au
[sfr@canb.auug.org.au: powerpc: fix up for removal of linux/bootmem.h]
Link: http://lkml.kernel.org/r/20181005161406.73ef8727@canb.auug.org.au
[sfr@canb.auug.org.au: x86/kaslr, ACPI/NUMA: fix for linux/bootmem.h removal]
Link: http://lkml.kernel.org/r/20181008190341.5e396491@canb.auug.org.au
Link: http://lkml.kernel.org/r/1536927045-23536-30-git-send-email-rppt@linux.vnet.ibm.com
Signed-off-by: Mike Rapoport
Signed-off-by: Stephen Rothwell
Acked-by: Michal Hocko
Cc: Catalin Marinas
Cc: Chris Zankel
Cc: "David S. Miller"
Cc: Geert Uytterhoeven
Cc: Greentime Hu
Cc: Greg Kroah-Hartman
Cc: Guan Xuetao
Cc: Ingo Molnar
Cc: "James E.J. Bottomley"
Cc: Jonas Bonn
Cc: Jonathan Corbet
Cc: Ley Foon Tan
Cc: Mark Salter
Cc: Martin Schwidefsky
Cc: Matt Turner
Cc: Michael Ellerman
Cc: Michal Simek
Cc: Palmer Dabbelt
Cc: Paul Burton
Cc: Richard Kuo
Cc: Richard Weinberger
Cc: Rich Felker
Cc: Russell King
Cc: Serge Semin
Cc: Thomas Gleixner
Cc: Tony Luck
Cc: Vineet Gupta
Cc: Yoshinori Sato
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Jun, 2018
1 commit
-
This is used in some systems from user space for determining the identity
of the device.Expose this as a file so that that user-space tools don't need to read
from /sys/firmware/dmi/tables/DMISigned-off-by: Simon Glass
Signed-off-by: Jean Delvare
14 Apr, 2018
1 commit
-
Pull dmi updates from Jean Delvare.
* 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
firmware: dmi_scan: Use lowercase letters for UUID
firmware: dmi_scan: Add DMI_OEM_STRING support to dmi_matches
firmware: dmi_scan: Fix UUID length safety check
13 Apr, 2018
3 commits
-
RFC 4122 asks for letters a-f in UUID to be lowercase. Follow this
recommendation.Suggested by Paul Dagnelie at:
https://savannah.nongnu.org/bugs/index.php?53569Signed-off-by: Jean Delvare
-
OEM strings are defined by each OEM and they contain customized and
useful OEM information. Supporting it provides more flexible uses of
the dmi_matches function.Signed-off-by: Alex Hung
Signed-off-by: Jean Delvare -
The test which ensures that the DMI type 1 structure is long enough
to hold the UUID is off by one. It would fail if the structure is
exactly 24 bytes long, while that's sufficient to hold the UUID.I don't expect this bug to cause problem in practice because all
implementations I have seen had length 8, 25 or 27 bytes, in line
with the SMBIOS specifications. But let's fix it still.Signed-off-by: Jean Delvare
Fixes: a814c3597a6b ("firmware: dmi_scan: Check DMI structure length")
Reviewed-by: Mika Westerberg
06 Apr, 2018
1 commit
-
Pull EDAC updates from Borislav Petkov:
"Noteworthy is the NVDIMM support:- NVDIMM support to EDAC (Tony Luck)
- misc fixes"
* tag 'edac_for_4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp:
EDAC, sb_edac: Remove variable length array usage
EDAC, skx_edac: Detect non-volatile DIMMs
firmware, DMI: Add function to look up a handle and return DIMM size
acpi, nfit: Add function to look up nvdimm device and provide SMBIOS handle
EDAC: Add new memory type for non-volatile DIMMs
EDAC: Drop duplicated array of strings for memory type names
EDAC, layerscape: Allow building for LS1021A
27 Mar, 2018
1 commit
-
Uninline dmi_get_bios_year() which, in particular, allows us
to optimize it in the future.While doing this, convert the function to return an error code
when BIOS date is not present or not parsable, or CONFIG_DMI=n.Additionally, during the move, add a bit of documentation.
Suggested-by: Bjorn Helgaas
Suggested-by: Rafael J. Wysocki
Signed-off-by: Andy Shevchenko
Reviewed-by: Jean Delvare
Reviewed-by: Rafael J. Wysocki
Acked-by: Thomas Gleixner
Cc: Bjorn Helgaas
Cc: Linus Torvalds
Cc: Lukas Wunner
Cc: Peter Zijlstra
Cc: Rafael J . Wysocki
Cc: linux-acpi@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Fixes: 492a1abd61e4 ("dmi: Introduce the dmi_get_bios_year() helper function")
Signed-off-by: Ingo Molnar
14 Mar, 2018
1 commit
-
When we first scan the SMBIOS table, save the size of the DIMM.
Provide a function for other code (EDAC driver) to look up the size
of a DIMM from its SMBIOS handle.Reviewed-by: Jean Delvare
Signed-off-by: Tony Luck
Cc: Aristeu Rozanski
Cc: Dan Williams
Cc: Len Brown
Cc: Mauro Carvalho Chehab
Cc: Qiuxu Zhuo
Cc: "Rafael J. Wysocki"
Cc: linux-acpi@vger.kernel.org
Cc: linux-nvdimm@lists.01.org
Link: http://lkml.kernel.org/r/20180312182430.10335-5-tony.luck@intel.com
Signed-off-by: Borislav Petkov
03 Feb, 2018
4 commits
-
Currently, when booting a kernel with DMI support on a platform that has
no DMI tables, the following output is emitted into the kernel log:[ 0.128818] DMI not present or invalid.
...
[ 1.306659] dmi: Firmware registration failed.
...
[ 2.908681] dmi-sysfs: dmi entry is absent.The first one is a pr_info(), but the subsequent ones are pr_err()s that
complain about a condition that is not really an error to begin with.So let's clean this up, and give up silently if dma_available is not set.
Signed-off-by: Ard Biesheuvel
Acked-by: Martin Hundebøll
Signed-off-by: Jean Delvare -
The handling of empty DMI strings looks quite broken to me:
* Strings from 1 to 7 spaces are not considered empty.
* True empty DMI strings (string index set to 0) are not considered
empty, and result in allocating a 0-char string.
* Strings with invalid index also result in allocating a 0-char
string.
* Strings starting with 8 spaces are all considered empty, even if
non-space characters follow (sounds like a weird thing to do, but
I have actually seen occurrences of this in DMI tables before.)
* Strings which are considered empty are reported as 8 spaces,
instead of being actually empty.Some of these issues are the result of an off-by-one error in memcmp,
the rest is incorrect by design.So let's get it square: missing strings and strings made of only
spaces, regardless of their length, should be treated as empty and
no memory should be allocated for them. All other strings are
non-empty and should be allocated.Signed-off-by: Jean Delvare
Fixes: 79da4721117f ("x86: fix DMI out of memory problems")
Cc: Parag Warudkar
Cc: Ingo Molnar
Cc: Thomas Gleixner -
I don't think it makes sense to check for a possible bad
initialization order at run time on every system when it is all
decided at build time.A more efficient way to make sure developers do not introduce new
calls to dmi_check_system() too early in the initialization sequence
is to simply document the expected call order. That way, developers
have a chance to get it right immediately, without having to
test-boot their kernel, wonder why it does not work, and parse the
kernel logs for a warning message. And we get rid of the run-time
performance penalty as a nice side effect.Signed-off-by: Jean Delvare
Cc: Ingo Molnar -
Function dmi_matches can me made a bit faster:
* The documented purpose of dmi_initialized is to catch too early
calls to dmi_check_system(). I'm not fully convinced it justifies
slowing down the initialization of all systems out there, but at
least the check should not have been moved from dmi_check_system()
to dmi_matches(). dmi_matches() is being called for every entry of
the table passed to dmi_check_system(), causing the same redundant
check to be performed again and again. So move it back to
dmi_check_system(), reverting this specific portion of commit
d7b1956fed33 ("DMI: Introduce dmi_first_match to make the interface
more flexible").* Don't check for the exact_match flag again when we already know its
value.Signed-off-by: Jean Delvare
Fixes: d7b1956fed33 ("DMI: Introduce dmi_first_match to make the interface more flexible")
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Rafael J. Wysocki
Cc: Jeff Garzik
15 Jun, 2017
3 commits
-
Before accessing DMI data to record it for later, we should ensure
that the DMI structures are large enough to contain the data in
question.Signed-off-by: Jean Delvare
Reviewed-by: Mika Westerberg
Cc: Dmitry Torokhov
Cc: Andy Shevchenko
Cc: Linus Walleij -
Currently they return -1 on error, which will confuse callers if
they try to interpret it as a normal negative error code.Signed-off-by: Andy Lutomirski
Signed-off-by: Darren Hart (VMware)
Signed-off-by: Jean Delvare -
Since version 3.0.0 of the SMBIOS specification, there can be
multiple entry points in memory, pointing to one or two DMI tables.
If both a 32-bit ("_SM_") entry point and a 64-bit ("_SM3_") entry
point are present, the specification requires that the latter points
to a table which is a super-set of the table pointed to by the
former. Therefore we should give preference to the 64-bit ("_SM3_")
entry point.However, currently the code is picking the first valid entry point
it finds. Per specification, we should look for a 64-bit ("_SM3_")
entry point first, and if we can't find any, look for a 32-bit
("_SM_" or "_DMI_") entry point. Modify the code to do that.Signed-off-by: Jean Delvare
23 May, 2017
1 commit
-
Sometimes it is more convenient to be able to match a whole family of
products, like in case of bunch of Chromebooks based on Intel_Strago to
apply a driver quirk instead of quirking each machine one-by-one.This adds support for DMI_PRODUCT_FAMILY identification string and also
exports it to the userspace through sysfs attribute just like the
existing ones.Suggested-by: Dmitry Torokhov
Signed-off-by: Mika Westerberg
Reviewed-by: Andy Shevchenko
Signed-off-by: Linus Walleij
19 Dec, 2016
1 commit
-
Let's keep consistent when print dmi_ids_string between SMBIOS 2.x
and SMBIOS 3.x, and always show the system identification string,
like Vendor, Product/Board name and BIOS infos.Signed-off-by: Kefeng Wang
Signed-off-by: Jean Delvare
16 Jan, 2016
4 commits
-
Save SMBIOS Type 9 System Slots during DMI scan. PCI address of
onboard devices was already saved but not for slots.Signed-off-by: Jordan Hargrave
Signed-off-by: Jean Delvare -
The description of dmi_find_device was apparently copied from a
similar function in a different subsystem, but the parameter names
were not adjusted as needed.Signed-off-by: Jean Delvare
Cc: Andrey Panin -
Get rid of the arbitrary 5-byte pointer offset, it served no purpose
and made it harder to match the code with the SMBIOS specification.Signed-off-by: Jean Delvare
Cc: Jordan Hargrave
Cc: Narendra K -
Calling dmi_string_nosave isn't cheap, so avoid calling it twice in a
row for the same string.Signed-off-by: Jean Delvare
Cc: Jordan Hargrave
Cc: Narendra K
08 Jan, 2016
1 commit
-
The dmi_ver wasn't updated correctly before the dmi_decode method run
to save the uuid.That resulted in "dmidecode -s system-uuid" and
/sys/class/dmi/id/product_uuid disagreeing. The latter was buggy and
this fixes it.Reported-by: Federico Simoncelli
Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists")
Fixes: 79bae42d51a5 ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()")
Signed-off-by: Andrea Arcangeli
Signed-off-by: Jean Delvare
25 Jun, 2015
5 commits
-
Signed-off-by: Jean Delvare
-
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.So this patch creates dmi/tables and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as
proposed by Jean Delvare.Tested-by: Roy Franz
Signed-off-by: Ivan Khoronzhuk
Signed-off-by: Jean Delvare -
The SMBIOS v3 entry points specify a maximum length for the DMI table,
not the exact length. Thus there may be garbage after the end-of-table
marker, which we don't want to export to user-space. Adjust dmi_len
when we find the end-of-table marker, so that only the actual table
payload is exported.Signed-off-by: Jean Delvare
Cc: Ivan Khoronzhuk -
The "dmi_table" function looks like data instance, but it does DMI
table decode. This patch renames it to "dmi_decode_table" name as
more appropriate. That allows us to use "dmi_table" name for correct
purposes.Signed-off-by: Ivan Khoronzhuk
Signed-off-by: Jean Delvare -
A 32-bit entry point to a DMI table says how many structures the table
contains. The SMBIOS specification explicitly says that end-of-table
markers should be ignored if they are not actually at the end of the
DMI table. So only honor the end-of-table marker for tables accessed
through 64-bit entry points, as they do not specify a structure count.Fixes: fc43026278 ("dmi: add support for SMBIOS 3.0 64-bit entry point")
Signed-off-by: Jean Delvare
Acked-by: Ard Biesheuvel
Cc: Leif Lindholm
Cc: Matt Fleming
14 May, 2015
2 commits
-
In function dmi_present(), dmi_walk_early() calls dmi_table(), which
calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last
function makes a decision based on the value of global variable
dmi_ver. The problem is that this variable is set right _after_
dmi_walk_early() returns. So dmi_save_uuid() always sees dmi_ver == 0
regardless of the actual version implemented.This causes /sys/class/dmi/id/product_uuid to always use the old
ordering even on systems implementing DMI/SMBIOS 2.6 or later, which
should use the new ordering.This is broken since kernel v3.8 for legacy DMI implementations and
since kernel v3.10 for SMBIOS 2 implementations. SMBIOS 3
implementations with the 64-bit entry point are not affected.The first breakage does not matter much as in practice legacy DMI
implementations are always for versions older than 2.6, which is when
the UUID ordering changed. The second breakage is more problematic as
it affects the vast majority of x86 systems manufactured since 2009.Signed-off-by: Jean Delvare
Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists")
Fixes: 79bae42d51a5 ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()")
Acked-by: Zhenzhong Duan
Cc: Ben Hutchings
Cc: Artem Savkov
Cc: Ivan Khoronzhuk
Cc: Matt Fleming
Cc: stable@vger.kernel.org [v3.10+] -
The trailing .x adds no information for the reader, and if anyone
tries to parse that line, this is more work as they have 3 different
formats to handle instead of 2. Plus, this makes backporting fixes
harder.Signed-off-by: Jean Delvare
Fixes: 95be58df74a5 ("firmware: dmi_scan: Use full dmi version for SMBIOS3")
Cc: Ivan Khoronzhuk
14 Apr, 2015
1 commit
-
Pull EFI update from Ingo Molnar:
"This tree includes various fixes, cleanups, a new efi=debug boot
option and EFI boot stub memory allocation optimizations"* 'core-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi/libstub: Retrieve FDT size when loaded from UEFI config table
efi: Clean up the efi_call_phys_[prolog|epilog]() save/restore interaction
efi: Disable interrupts around EFI calls, not in the epilog/prolog calls
x86/efi: Add a "debug" option to the efi= cmdline
firmware: dmi_scan: Use direct access to static vars
firmware: dmi_scan: Use full dmi version for SMBIOS3
27 Mar, 2015
1 commit
-
dmi_num is a u16, dmi_len is a u32, so this construct:
dmi_num = dmi_len / 4;
would result in an integer overflow for a DMI table larger than
256 kB. I've never see such a large table so far, but SMBIOS 3.0
makes it possible so maybe we'll see such tables in the future.So instead of faking a structure count when the entry point does
not provide it, adjust the loop condition in dmi_table() to properly
deal with the case where dmi_num is not set.This bug was introduced with the initial SMBIOS 3.0 support in commit
fc43026278b2 ("dmi: add support for SMBIOS 3.0 64-bit entry point").Signed-off-by: Jean Delvare
Cc: Matt Fleming
Cc: Ivan Khoronzhuk
Cc:
Acked-by: Ard Biesheuvel
Signed-off-by: Matt Fleming