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>] [day] [month] [year] [list]
Message-ID: <20130912142537.GA10143@x1.alien8.de>
Date:	Thu, 12 Sep 2013 16:25:37 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Dave Young <dyoung@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, kexec@...ts.infradead.org,
	akpm@...ux-foundation.org, zohar@...ux.vnet.ibm.com,
	d.kasatkin@...sung.com, ebiederm@...ssion.com,
	matthew.garrett@...ula.com
Subject: Re: [PATCH 15/16] bootparam: Pass acpi_rsdp pointer in bootparam

On Thu, Sep 12, 2013 at 09:19:30AM -0400, Vivek Goyal wrote:
> I did not understand this argument that we need to use high virtual
> addresses because windows is using it and now we end up creating
> fixed EFI addresses and that becomes an ABI. If EFI implementations

The only thing that becomes sort-of ABI is that we start the mappings at
-4G virtual.

> are dependent on high addresses being passed, shouldn't it be those
> implementations which need to be fixed instead of kernel fixing EFI

Right, this is the biggest issue with firmware - vendors like to declare
those as End-of-Life platforms and for them there are no fixes. This is
the reason why we don't do the 1:1 mappings.

> addresses in higher region.

The thing is, reportedly some Apple UEFI implementations cannot stomach
1:1 SetVirtualAddressMap mappings. Also, the high addresses mappings is
the only thing that vendors test on windoze so in that field we want
to do what windoze does as this is the only thing that gets reliable
testing.

But I get the feeling we're feeling up stuff in the dark as firmware is
closed crap which we cannot look at.

HTH.

-- 
Regards/Gruss,
Boris.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ