On Fri, Aug 04, 2023 at 08:47:53AM +0300, Andy Shevchenko wrote:
> 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@xxxxxxxxxx>
> > Cc: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
>
> 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.
>
Thanks!, Andy. I specifically wanted Ard and Alex to look at this patch
and hence added Cc. I was not aware that no blank line should be there.
Thanks for letting me know.
> > Signed-off-by: Sunil V L <sunilvl@xxxxxxxxxxxxxxxx>
>
> ...
>
> > #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)?
>
Yeah, sure. Let me update in next version.
> ...
>
> > + 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.)
>
Okay. This is copied from arm64 version. But I think this is a good
point. Let me just print the warning message without address in the next
version.
Thanks!
Sunil
