[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZMyRCRRkTnR/sK0u@smile.fi.intel.com>
Date: Fri, 4 Aug 2023 08:47:53 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Sunil V L <sunilvl@...tanamicro.com>
Cc: linux-doc@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org,
Jonathan Corbet <corbet@....net>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>,
Daniel Scally <djrscally@...il.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Anup Patel <anup@...infault.org>,
Marc Zyngier <maz@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Robert Moore <robert.moore@...el.com>,
Haibo Xu <haibo1.xu@...el.com>,
Andrew Jones <ajones@...tanamicro.com>,
Conor Dooley <conor.dooley@...rochip.com>,
Atish Kumar Patra <atishp@...osinc.com>,
Ard Biesheuvel <ardb@...nel.org>,
Alexandre Ghiti <alexghiti@...osinc.com>
Subject: Re: [RFC PATCH v1 04/21] RISC-V: ACPI: Enhance acpi_os_ioremap with
MMIO remapping
On Thu, Aug 03, 2023 at 11:28:59PM +0530, Sunil V L wrote:
> Enhance the acpi_os_ioremap() to support opregions in MMIO
> space. Also, have strict checks using EFI memory map
> to allow remapping the RAM similar to arm64.
>
> Cc: Ard Biesheuvel <ardb@...nel.org>
> Cc: Alexandre Ghiti <alexghiti@...osinc.com>
You may use --cc to the command line when forming patches.
Also we usually consider Cc: as a part of the tag block, meaning no blank line
should be here.
> Signed-off-by: Sunil V L <sunilvl@...tanamicro.com>
...
> #include <linux/io.h>
> #include <linux/pci.h>
> #include <linux/efi.h>
> +#include <linux/memblock.h>
Can you squeeze it to have some order, like to be after io.h (taking into
account given context)?
...
> + if (memblock_is_map_memory(phys) ||
> + !memblock_is_region_memory(phys, size)) {
> + pr_warn(FW_BUG "requested region covers kernel memory @ %p\n",
> + &phys);
How %p can be useful here (it's mangled), but also wouldn't this give a hint to
an attacker about the kernel memory location and diminish the KASLR protection?
(IIRC after boot we always have the same salt for the mangling the pointers when
printing, so at least theoretically it might be possible to bruteforce the
printing algo to give a clue about the kernel address.)
> + return NULL;
> + }
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists