linux-kernel - Re: [PATCH 00/22] Introducing the TI Keystone platform

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:	Wed, 8 Aug 2012 16:43:18 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Cyril Chemparathy <cyril@...com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"arnd@...db.de" <arnd@...db.de>,
	"nico@...aro.org" <nico@...aro.org>,
	Will Deacon <Will.Deacon@....com>
Subject: Re: [PATCH 00/22] Introducing the TI Keystone platform

On Sun, Aug 05, 2012 at 04:10:34PM +0100, Cyril Chemparathy wrote:
> On 8/4/2012 4:39 AM, Russell King - ARM Linux wrote:
> > On Tue, Jul 31, 2012 at 07:04:36PM -0400, Cyril Chemparathy wrote:
> >> This series is a follow on to the RFC series posted earlier (archived at [1]).
> >> The major change introduced here is the modification to the kernel patching
> >> mechanism for phys_to_virt/virt_to_phys, in order to support LPAE platforms
> >> that require late patching.  In addition to these changes, we've updated the
> >> series based on feedback from the earlier posting.
> >>
> >> Most of the patches in this series are fixes and extensions to LPAE support on
> >> ARM. The last three patches in this series are specific to the TI Keystone
> >> platform, and are being provided here for the sake of completeness.  These
> >> three patches are dependent on the smpops patch set (see [2]), and are not
> >> ready to be merged in as yet.
> >
> > Can you explain why you want the kernel loaded above the 4GB watermark?
> > This seems silly to me, as the kernel needs to run at points with a 1:1
> > physical to virtual mapping, and you can't do that if the kernel is
> > stored in physical memory above the 4GB watermark.
[...]
> We are well aware of the fact that we are barely scratching the surface 
> of the problem space here, and we'd be very thankful for a heads up on 
> issues that we may have missed so far.

Another thing to be aware is that apart from a virtual alias between the
kernel mapping and the idmap, you now introduce a physical alias as well
and the caches (physically tagged) get confused.

-- 
Catalin
--
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/