linux-kernel - Re: [PATCH] x86: access to efi reserved memory type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49B44BE8.1080700@zytor.com>
Date:	Sun, 08 Mar 2009 15:51:20 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Cliff Wickman <cpw@....com>
CC:	linux-kernel@...r.kernel.org, mingo@...e.hu
Subject: Re: [PATCH] x86: access to efi reserved memory type

Cliff Wickman wrote:
> From: Cliff Wickman <cpw@....com>
> 
>  (this patch dates back to 2008-11-06
>     http://marc.info/?l=linux-kernel&m=122600658522471&w=2
>   but has never been applied.)
> 
> Give drivers addresses of memory type EFI_RESERVED_TYPE.
> This supports drivers that use vendor-specific memory, available
> only to special devices.
> 
> The walk() function scans the EFI memory map and does a callback to a
> specified function for each memory area of a specified type.
> efi_memmap_walk_reserved() provides a scan for type EFI_RESERVED_TYPE.
>  (an earlier version of this patch had proposed a new EFI type, but
>   EFI_RESERVED_TYPE should be sufficient, given that the firmware follows
>   the standard and does not use such memory for its own purposes)
> 
> A UV driver will be posted to the community in the future that will use
> these routines.
> 
> Tested on 2.6.29-rc7 (and many previous versions) running on a
> UV hardware simulator.
> 

I have multiple issues with this patch.

FIRST, this is identical to a platform driver.  I really don't
understand why it should need a special interface.

SECOND, the EFI-specific callback interface is just plain weird.

THIRD, saying "A UV driver will be posted to the community in the future
that will use these routines" is not exactly motivation.  At no point
are you technically justifying this code.

In particular, I really want to know why a plain platform device is
insufficient, and look for a better solution than this, using the
generic memory map interfaces rather than something EFI-specific.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/