From: Greg KH <gregkh@linuxfoundation.org>
To: Hans-Gert Dahmen <hans-gert.dahmen@immu.ne>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
philipp.deppenwiese@immu.ne
Subject: Re: [PATCH] firmware: export x86_64 platform flash bios region via sysfs
Date: Tue, 22 Jun 2021 22:02:40 +0200 [thread overview]
Message-ID: <YNJB4HoRa6qWgOJC@kroah.com> (raw)
In-Reply-To: <20210622142334.14883-1-hans-gert.dahmen@immu.ne>
On Tue, Jun 22, 2021 at 04:23:34PM +0200, Hans-Gert Dahmen wrote:
> Make the 16MiB long memory-mapped BIOS region of the platform SPI flash
> on X86_64 system available via /sys/kernel/firmware/flash_mmap/bios_region
> for pen-testing, security analysis and malware detection on kernels
> which restrict module loading and/or access to /dev/mem.
>
> It will be used by the open source Converged Security Suite.
> https://github.com/9elements/converged-security-suite
>
> Signed-off-by: Hans-Gert Dahmen <hans-gert.dahmen@immu.ne>
> ---
> drivers/firmware/Kconfig | 9 ++++
> drivers/firmware/Makefile | 1 +
> drivers/firmware/x86_64_flash_mmap.c | 65 ++++++++++++++++++++++++++++
> 3 files changed, 75 insertions(+)
> create mode 100644 drivers/firmware/x86_64_flash_mmap.c
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index db0ea2d2d75a..bd77ca2b4fa6 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -296,6 +296,15 @@ config TURRIS_MOX_RWTM
> other manufacturing data and also utilize the Entropy Bit Generator
> for hardware random number generation.
>
> +config X86_64_FLASH_MMAP
> + tristate "Export platform flash memory-mapped BIOS region"
> + depends on X86_64
> + help
> + Export the memory-mapped BIOS region of the platform SPI flash as
> + a read-only sysfs binary attribute on X86_64 systems. The first 16MiB
> + will be accessible via /sys/kernel/firmware/flash_mmap/bios_region
> + for security and malware analysis for example.
Module name information here?
Can this be auto-loaded based on hardware-specific values somewhere?
Otherwise it just looks like if this module loads, it will "always
work"?
And why would you want to map the bios into userspace?
What bios, UEFI?
And you need a Documentation/ABI/ update for new sysfs files.
> +
> source "drivers/firmware/broadcom/Kconfig"
> source "drivers/firmware/google/Kconfig"
> source "drivers/firmware/efi/Kconfig"
> diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
> index 5e013b6a3692..eb7483c5a2ac 100644
> --- a/drivers/firmware/Makefile
> +++ b/drivers/firmware/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_QCOM_SCM) += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
> obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
> obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o
> obj-$(CONFIG_TURRIS_MOX_RWTM) += turris-mox-rwtm.o
> +obj-$(CONFIG_X86_64_FLASH_MMAP) += x86_64_flash_mmap.o
>
> obj-y += arm_scmi/
> obj-y += broadcom/
> diff --git a/drivers/firmware/x86_64_flash_mmap.c b/drivers/firmware/x86_64_flash_mmap.c
> new file mode 100644
> index 000000000000..f9d871a8b516
> --- /dev/null
> +++ b/drivers/firmware/x86_64_flash_mmap.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Export the memory-mapped BIOS region of the platform SPI flash as
> + * a read-only sysfs binary attribute on X86_64 systems.
> + *
> + * Copyright © 2021 immune GmbH
> + */
> +
> +#include <linux/version.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/io.h>
> +#include <linux/sysfs.h>
> +#include <linux/kobject.h>
> +
> +#define FLASH_REGION_START 0xFF000000ULL
> +#define FLASH_REGION_SIZE 0x1000000ULL
Where do these values come from?
> +#define FLASH_REGION_MASK (FLASH_REGION_SIZE - 1)
> +
> +struct kobject *kobj_ref;
Only 1? Not per-hardware-device?
> +
> +static ssize_t bios_region_read(struct file *file, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buffer,
> + loff_t offset, size_t count)
> +{
> + resource_size_t pa = FLASH_REGION_START + (offset & FLASH_REGION_MASK);
> + void __iomem *va = ioremap(pa, PAGE_SIZE);
Why PAGE_SIZE?
> +
> + memcpy_fromio(buffer, va, PAGE_SIZE);
> + iounmap(va);
> +
> + return min(count, PAGE_SIZE);
> +}
> +
> +BIN_ATTR_RO(bios_region, FLASH_REGION_SIZE);
> +
> +static int __init flash_mmap_init(void)
> +{
> + int ret = 0;
> +
> + kobj_ref = kobject_create_and_add("flash_mmap", firmware_kobj);
> + ret = sysfs_create_bin_file(kobj_ref, &bin_attr_bios_region);
You just raced with userspace and lost :(
Please make a sysfs attribute part of a default "group" for a kobject.
But as you are using a "raw" kobject here, that feels really wrong to
me. Isn't this some sort of platform device really? Why not go that
way, why tie this to the firmware subsystem?
> + if (ret) {
> + pr_err("sysfs_create_bin_file failed\n");
> + goto error;
> + }
> +
> + return ret;
So this just "always works"? That feels VERY dangerous.
As this is a x86 thing, you should also cc: the x86 maintainers.
thanks,
greg k-h
next prev parent reply other threads:[~2021-06-22 20:02 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 14:23 [PATCH] firmware: export x86_64 platform flash bios region via sysfs Hans-Gert Dahmen
2021-06-22 20:02 ` Greg KH [this message]
2021-06-25 13:54 ` Hans-Gert Dahmen
2021-06-22 22:18 ` David Laight
2021-06-23 12:17 ` Hans-Gert Dahmen
2021-06-23 12:40 ` gregkh
2021-06-24 11:20 ` Hans-Gert Dahmen
2021-06-24 11:42 ` gregkh
2021-06-23 13:22 ` David Laight
-- strict thread matches above, loose matches on Subject: below --
2021-11-09 0:01 Hans-Gert Dahmen
2021-11-09 6:16 ` Greg KH
2021-11-09 8:52 ` Hans-Gert Dahmen
2021-11-09 8:56 ` Hans-Gert Dahmen
2021-11-09 10:28 ` Greg KH
2021-11-09 12:32 ` Hans-Gert Dahmen
2021-11-09 12:42 ` Greg KH
2021-11-09 14:09 ` Mauro Lima
2021-11-09 14:11 ` Mauro Lima
2021-11-09 14:10 ` Hans-Gert Dahmen
[not found] ` <CAHp75VfbYsyC=7Ncnex1f_jiwrZhExDF7iy4oSGZgS1cHmsN0Q@mail.gmail.com>
2021-11-10 8:37 ` Hans-Gert Dahmen
2021-11-10 9:04 ` Andy Shevchenko
2021-11-10 9:17 ` Hans-Gert Dahmen
2021-11-10 9:25 ` Andy Shevchenko
2021-11-10 10:00 ` Hans-Gert Dahmen
2021-11-10 13:13 ` Mauro Lima
2021-11-10 16:31 ` Andy Shevchenko
2021-11-10 17:37 ` Mauro Lima
2021-11-11 6:42 ` Mika Westerberg
2021-11-11 8:59 ` Hans-Gert Dahmen
2021-11-11 10:32 ` Mika Westerberg
2021-11-11 10:55 ` Hans-Gert Dahmen
2021-11-11 11:43 ` Greg KH
2021-11-11 11:46 ` Richard Hughes
2021-11-11 12:46 ` Andy Shevchenko
2021-11-11 12:56 ` Hans-Gert Dahmen
2021-11-11 13:54 ` Andy Shevchenko
2021-11-11 14:33 ` Hans-Gert Dahmen
2021-11-11 15:30 ` Andy Shevchenko
2021-11-11 15:43 ` Ard Biesheuvel
2021-11-11 15:49 ` Andy Shevchenko
2021-11-11 16:05 ` Hans-Gert Dahmen
2021-11-11 21:07 ` Richard Hughes
2021-11-12 6:52 ` Greg KH
2021-11-12 10:09 ` Richard Hughes
2021-11-12 10:43 ` Greg KH
2021-11-12 12:25 ` Hans-Gert Dahmen
2021-11-11 16:07 ` Hans-Gert Dahmen
2021-11-11 16:44 ` Andy Shevchenko
2021-11-11 16:55 ` Hans-Gert Dahmen
2021-11-11 17:48 ` Andy Shevchenko
2021-11-11 18:14 ` Hans-Gert Dahmen
2021-11-11 19:14 ` Ard Biesheuvel
2021-11-11 20:50 ` Hans-Gert Dahmen
2021-11-11 13:00 ` Mika Westerberg
2021-11-11 13:22 ` Richard Hughes
2021-11-11 13:34 ` Mika Westerberg
2021-11-11 13:36 ` Hans-Gert Dahmen
2021-11-11 14:42 ` Mauro Lima
2021-11-11 15:06 ` Mika Westerberg
2021-11-11 15:16 ` Hans-Gert Dahmen
2021-11-12 6:59 ` Mika Westerberg
2021-11-11 15:31 ` Mauro Lima
2021-11-11 11:50 ` Mauro Lima
2021-11-10 17:41 ` Hans-Gert Dahmen
[not found] ` <E1CBFD23-AC3B-43BF-BF0A-158844486BA9@getmailspring.com>
2021-11-09 10:24 ` Greg KH
2021-11-09 10:30 ` Philipp Deppenwiese
2021-11-09 11:25 ` Greg KH
2021-11-09 13:55 ` Mauro Lima
2021-11-09 16:12 ` Greg KH
2021-11-09 17:23 ` Mauro Lima
2021-06-18 16:47 Hans-Gert Dahmen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YNJB4HoRa6qWgOJC@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=hans-gert.dahmen@immu.ne \
--cc=linux-kernel@vger.kernel.org \
--cc=philipp.deppenwiese@immu.ne \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox