linux-kernel - Re: [RFC 1/2] ACPI: activate&export acpi_os_get_physical

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]

Date:	Fri, 1 May 2015 05:56:19 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Darren Hart <dvhart@...radead.org>, Kast Bernd <kastbernd@....de>,
	corentin.chary@...il.com, lenb@...nel.org,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	acpi4asus-user@...ts.sourceforge.net,
	platform-driver-x86@...r.kernel.org
Subject: Re: [RFC 1/2] ACPI: activate&export acpi_os_get_physical_address

On Fri, May 01, 2015 at 03:45:52AM +0200, Rafael J. Wysocki wrote:

> And I don't really understand the Matthew's comment regarding limiting
> operation regions to system memory.  This is about a specific operation
> region (which BTW only seems to be used as a means to access system memory
> at the location pointed to by the arg) in that particular method.

My feeling was that it really ought to have been the ACPI code dealing 
with this in some way, but having looked at it again I accept that this 
is really something that's limited by the vendor implementation. 
virt_to_phys() isn't the worst thing to do here.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/