linux-kernel - RE: [PATCHv8 00/12] Contiguous Memory Allocator

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: <02a71d80302932190e8edfddf82b7895@mail.gmail.com>
Date:	Tue, 4 Jan 2011 23:01:39 +0530
From:	Santosh Shilimkar <santosh.shilimkar@...com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Johan MOSSBERG <johan.xx.mossberg@...ricsson.com>
Cc:	Daniel Walker <dwalker@...eaurora.org>,
	Kyungmin Park <kmpark@...radead.org>,
	Mel Gorman <mel@....ul.ie>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Michal Nazarewicz <m.nazarewicz@...sung.com>,
	linux-kernel@...r.kernel.org,
	Michal Nazarewicz <mina86@...a86.com>, linux-mm@...ck.org,
	Ankita Garg <ankita@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org
Subject: RE: [PATCHv8 00/12] Contiguous Memory Allocator

> -----Original Message-----
> From: linux-arm-kernel-bounces@...ts.infradead.org [mailto:linux-
> arm-kernel-bounces@...ts.infradead.org] On Behalf Of Russell King -
> ARM Linux
> Sent: Tuesday, January 04, 2011 10:49 PM
> To: Johan MOSSBERG
> Cc: Daniel Walker; Kyungmin Park; Mel Gorman; KAMEZAWA Hiroyuki;
> Michal Nazarewicz; linux-kernel@...r.kernel.org; Michal Nazarewicz;
> linux-mm@...ck.org; Ankita Garg; Andrew Morton; Marek Szyprowski;
> linux-arm-kernel@...ts.infradead.org; linux-media@...r.kernel.org
> Subject: Re: [PATCHv8 00/12] Contiguous Memory Allocator
>
> On Tue, Jan 04, 2011 at 05:23:37PM +0100, Johan MOSSBERG wrote:
> > Russell King wrote:
> > > Has anyone addressed my issue with it that this is wide-open for
> > > abuse by allocating large chunks of memory, and then remapping
> > > them in some way with different attributes, thereby violating
> the
> > > ARM architecture specification?
> >
> > I seem to have missed the previous discussion about this issue.
> > Where in the specification (preferably ARMv7) can I find
> > information about this?
>
> Here's the extracts from the architecture reference manual:
>
> * If the same memory locations are marked as having different
>   cacheability attributes, for example by the use of aliases in a
>   virtual to physical address mapping, behavior is UNPREDICTABLE.
>
> A3.5.7 Memory access restrictions
>
> Behavior is UNPREDICTABLE if the same memory location:
> * is marked as Shareable Normal and Non-shareable Normal
> * is marked as having different memory types (Normal, Device, or
>   Strongly-ordered)
> * is marked as having different cacheability attributes
> * is marked as being Shareable Device and Non-shareable Device
> memory.
>
> Such memory marking contradictions can occur, for example, by the
> use of
> aliases in a virtual to physical address mapping.
>
> Glossary:
> UNPREDICTABLE
> Means the behavior cannot be relied upon. UNPREDICTABLE behavior
> must not
> represent security holes.  UNPREDICTABLE behavior must not halt or
> hang
> the processor, or any parts of the system. UNPREDICTABLE behavior
> must not
> be documented or promoted as having a defined effect.
>
> > Is the problem that it is simply
> > forbidden to map an address multiple times with different cache
> > setting and if this is done the hardware might start failing? Or
> > is the problem that having an address mapped cached means that
> > speculative pre-fetch can read it into the cache at any time,
> > possibly causing problems if an un-cached mapping exists? In my
> > opinion option number two can be handled and I've made an attempt
> > at doing that in hwmem (posted on linux-mm a while ago), look in
> > cache_handler.c. Hwmem currently does not use cma but the next
> > version probably will.
>
> Given the extract from the architecture reference manual, do you
> want
> to run a system where you can't predict what the behaviour will be
> if
> you have two mappings present, one which is cacheable and one which
> is
> non-cacheable, and you're relying on the non-cacheable mapping to
> never
> return data from the cache?
>
> What if during your testing, it appears to work correctly, but out
> in
> the field, someone's loaded a different application to your setup
> resulting in different memory access patterns, causing cache lines
> to
> appear in the non-cacheable mapping, and then the CPU hits them on
> subsequent accesses corrupting data...
>
> You can't say that will never happen if you're relying on this
> unpredictable behaviour.
>
Just to add to Russell's point, we did land up in un-traceable
CPU deadlocks while running the kernel which was violating some of
the rules set by ARM ARM.
The usecase use to work ~98% of the time.

Regards,
Santosh
--
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/