firmware: dmi: Constify 'struct bin_attribute'

The sysfs core now allows instances of 'struct bin_attribute' to be
moved into read-only memory. Make use of that to protect them against
accidental or

firmware: dmi: Constify 'struct bin_attribute'

The sysfs core now allows instances of 'struct bin_attribute' to be
moved into read-only memory. Make use of that to protect them against
accidental or malicious modifications.

Signed-off-by: Thomas Weißschuh <[email protected]>
Link: https://lore.kernel.org/r/20250125-sysfs-const-bin_attr-dmi-v2-3-ece1895936f4@weissschuh.net
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: dmi: Define bin_attributes through macro

The macro makes the code shorter and simplifies constification of the
callback arguments.

Signed-off-by: Thomas Weißschuh <[email protected]>
L

firmware: dmi: Define bin_attributes through macro

The macro makes the code shorter and simplifies constification of the
callback arguments.

Signed-off-by: Thomas Weißschuh <[email protected]>
Link: https://lore.kernel.org/r/20250125-sysfs-const-bin_attr-dmi-v2-2-ece1895936f4@weissschuh.net
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: dmi-sysfs: handle HAS_IOPORT=n

In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to guard sections of code calling them
as alternative

firmware: dmi-sysfs: handle HAS_IOPORT=n

In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to guard sections of code calling them
as alternative access methods.

Co-developed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Niklas Schnelle <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: dmi-sysfs: make kobj_type structures constant

Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.

Take advantag

firmware: dmi-sysfs: make kobj_type structures constant

Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.

Take advantage of this to constify the structure definitions to prevent
modification at runtime.

Signed-off-by: Thomas Weißschuh <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle

KASAN reported a null-ptr-deref error:

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 1373 C

firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle

KASAN reported a null-ptr-deref error:

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 1373 Comm: modprobe
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:dmi_sysfs_entry_release
...
Call Trace:
<TASK>
kobject_put
dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs
dmi_decode_table (drivers/firmware/dmi_scan.c:133)
dmi_walk (drivers/firmware/dmi_scan.c:1115)
dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs
do_one_initcall (init/main.c:1296)
...
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x4000000 from 0xffffffff81000000
---[ end Kernel panic - not syncing: Fatal exception ]---

It is because previous patch added kobject_put() to release the memory
which will call dmi_sysfs_entry_release() and list_del().

However, list_add_tail(entry->list) is called after the error block,
so the list_head is uninitialized and cannot be deleted.

Move error handling to after list_add_tail to fix this.

Fixes: 660ba678f999 ("firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle")
Signed-off-by: Chen Zhongjin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: dmi-sysfs: make pr_info messages rate limited

Currently if a process repeat repeatedly reads the dmi sysfs raw event log
/sys/firmware/dmi/entries/15-0/system_event_log/raw_event_log when

firmware: dmi-sysfs: make pr_info messages rate limited

Currently if a process repeat repeatedly reads the dmi sysfs raw event log
/sys/firmware/dmi/entries/15-0/system_event_log/raw_event_log when GPNV
support is missing or using an unknown access method the kernel log gets
spammed with info messages. Make the messages rate limited to reduce the
message spamming. Triggered when running sudo stress-ng --sysfs -t 5m.

Signed-off-by: Colin Ian King <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle

kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add()

If this function retur

firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle

kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add()

If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.

Fix this issue by calling kobject_put().

Fixes: 948af1f0bbc8 ("firmware: Basic dmi-sysfs support")
Signed-off-by: Miaoqian Lin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: dmi-sysfs: use default_groups in kobj_type

There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move t

firmware: dmi-sysfs: use default_groups in kobj_type

There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the firmware dmi-sysfs sysfs code to use default_groups
field which has been the preferred way since aa30f47cf666 ("kobject: Add
support for default attribute groups to kobj_type") so that we can soon
get rid of the obsolete default_attrs field.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: dmi-sysfs: Replace zero-length array with flexible-array member

There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a s

firmware: dmi-sysfs: Replace zero-length array with flexible-array member

There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure. Kernel code should
always use “flexible array members”[1] for these cases. The older style of
one-element or zero-length arrays should no longer be used[2].

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://github.com/KSPP/linux/issues/21

Signed-off-by: Gustavo A. R. Silva <[email protected]>

show more ...

treewide: Add SPDX license identifier for more missed files

Add SPDX license identifiers to all files which:

- Have no license information of any form

- Have MODULE_LICENCE("GPL*") inside which

treewide: Add SPDX license identifier for more missed files

Add SPDX license identifiers to all files which:

- Have no license information of any form

- Have MODULE_LICENCE("GPL*") inside which was used in the initial
scan/conversion to ignore the file

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

GPL-2.0-only

Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: dmi: handle missing DMI data gracefully

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:

[

firmware: dmi: handle missing DMI data gracefully

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 <[email protected]>
Acked-by: Martin Hundebøll <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>

show more ...

x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap() for RAM mappings

The ioremap() function is intended for mapping MMIO. For RAM, the
memremap() function should be used. Convert calls fro

x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap() for RAM mappings

The ioremap() function is intended for mapping MMIO. For RAM, the
memremap() function should be used. Convert calls from ioremap() to
memremap() when re-mapping RAM.

This will be used later by SME to control how the encryption mask is
applied to memory mappings, with certain memory locations being mapped
decrypted vs encrypted.

Signed-off-by: Tom Lendacky <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Reviewed-by: Borislav Petkov <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brijesh Singh <[email protected]>
Cc: Dave Young <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Konrad Rzeszutek Wilk <[email protected]>
Cc: Larry Woodman <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: Michael S. Tsirkin <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Radim Krčmář <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Toshimitsu Kani <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/b13fccb9abbd547a7eef7b1fdfc223431b211c88.1500319216.git.thomas.lendacky@amd.com
Signed-off-by: Ingo Molnar <[email protected]>

show more ...

firmware: dmi_scan: add SBMIOS entry and DMI tables

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currentl

firmware: dmi_scan: add SBMIOS entry and DMI tables

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 <[email protected]>
Signed-off-by: Ivan Khoronzhuk <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>

show more ...

firmware: dmi-sysfs: Remove "dmi" directory on module exit

With CONFIG_DEBUG_KOBJECT_RELEASE=y, removing and immediately reloading the
dmi-sysfs module causes the following warning:

sysfs: cannot

firmware: dmi-sysfs: Remove "dmi" directory on module exit

With CONFIG_DEBUG_KOBJECT_RELEASE=y, removing and immediately reloading the
dmi-sysfs module causes the following warning:

sysfs: cannot create duplicate filename '/firmware/dmi'
kobject_add_internal failed for dmi with -EEXIST, don't try to register things with the same name in the same directory.

The "dmi" directory stays in sysfs until the dmi_kobj is released, and
DEBUG_KOBJECT_RELEASE delays that.

I don't think we can hit this problem in normal usage because dmi_kobj is
static and nothing outside dmi-sysfs can get a reference to it, so the
only way to delay the "dmi" release is with DEBUG_KOBJECT_RELEASE.

Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: dmi-sysfs: Don't remove dmi-sysfs "raw" file explicitly

Removing the dmi-sysfs module causes the following warning:

# modprobe -r dmi_sysfs
WARNING: CPU: 11 PID: 6785 at fs/sysfs/inod

firmware: dmi-sysfs: Don't remove dmi-sysfs "raw" file explicitly

Removing the dmi-sysfs module causes the following warning:

# modprobe -r dmi_sysfs
WARNING: CPU: 11 PID: 6785 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
sysfs: can not remove 'raw', no directory

This is because putting the entry kobject, e.g., for
"/sys/firmware/dmi/entries/19-0", removes the directory and all its
contents. By the time dmi_sysfs_entry_release() runs, the "raw" file
inside ".../19-0/" has already been removed.

Therefore, we don't need to remove the "raw" bin file at all in
dmi_sysfs_entry_release().

Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: Fix unaligned memory accesses in dmi-sysfs

DMI entries are arranged in memory back to back with no alignment
guarantees. This means that the struct dmi_header passed to callbacks
from dmi_

firmware: Fix unaligned memory accesses in dmi-sysfs

DMI entries are arranged in memory back to back with no alignment
guarantees. This means that the struct dmi_header passed to callbacks
from dmi_walk() itself isn't byte aligned. This causes problems on
architectures that expect aligned data, such as IA64.

The dmi-sysfs patchset introduced structure member accesses through this
passed in dmi_header. Fix this by memcpy()ing the structures to
temporary locations on stack when inspecting/copying them.

Signed-off-by: Mike Waychison <[email protected]>
Tested-by: Tony Luck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: Expose DMI type 15 System Event Log

The System Event Log described by DMI entry type 15 may be backed by
either memory or may be indirectly accessed via an IO index/data
register pair.

In

firmware: Expose DMI type 15 System Event Log

The System Event Log described by DMI entry type 15 may be backed by
either memory or may be indirectly accessed via an IO index/data
register pair.

In order to get read access to this log, expose it in the
"system_event_log" sub-directory of type 15 DMI entries, ie:
/sys/firmware/dmi/entries/15-0/system_event_log/raw_event_log.

This commit handles both IO accessed and memory access system event
logs. OEM specific access and GPNV support is explicitly not handled
and we error out in the logs when we do not recognize the access method.

Signed-off-by: Mike Waychison <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: Break out system_event_log in dmi-sysfs

The optional type 15 entry of the DMI table describes a non-volatile
storage-backed system event log.

In preparation for the next commit which expo

firmware: Break out system_event_log in dmi-sysfs

The optional type 15 entry of the DMI table describes a non-volatile
storage-backed system event log.

In preparation for the next commit which exposes the raw bits of the
event log to userland, create a new sub-directory within the dmi entry
called "system_event_log" and expose attribute files that describe the
event log itself.

Currently, only a single child object is permitted within a
dmi_sysfs_entry. We simply point at this child from the dmi_sysfs_entry
if it exists.

Signed-off-by: Mike Waychison <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

firmware: Basic dmi-sysfs support

Introduce a new module "dmi-sysfs" that exports the broken out entries
of the DMI table through sysfs.

Entries are enumerated via dmi_walk() on module load, and ar

firmware: Basic dmi-sysfs support

Introduce a new module "dmi-sysfs" that exports the broken out entries
of the DMI table through sysfs.

Entries are enumerated via dmi_walk() on module load, and are populated
as kobjects rooted at /sys/firmware/dmi/entries.

Entries are named "<type>-<instance>", where:
<type> : is the type of the entry, and
<instance> : is the ordinal count within the DMI table of that
entry type. This instance is used in lieu the DMI
entry's handle as no assurances are made by the kernel
that handles are unique.

All entries export the following attributes:
length : The length of the formatted portion of the entry
handle : The handle given to this entry by the firmware
raw : The raw bytes of the entire entry, including the
formatted portion, the unformatted (strings) portion,
and the two terminating nul characters.
type : The DMI entry type
instance : The ordinal instance of this entry given its type.
position : The position ordinal of the entry within the table in
its entirety.

Entries in dmi-sysfs are kobject backed members called "struct
dmi_sysfs_entry" and belong to dmi_kset. They are threaded through
entry_list (protected by entry_list_lock) so that we can find them at
cleanup time.

Signed-off-by: Mike Waychison <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...