linux-kernel - Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

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: <20070507012418.GB25739@linux-sh.org>
Date:	Mon, 7 May 2007 10:24:18 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Greg Ungerer <gerg@...pgear.com>
Cc:	Robin Getz <rgetz@...ckfin.uclinux.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH]: linux-2.6.21-uc0 (MMU-less updates)

On Thu, May 03, 2007 at 11:30:53PM +1000, Greg Ungerer wrote:
> Robin Getz wrote:
> >>Its not an architecture problem. It can effect any board that
> >>has RAM mapped at a large numerical addresses (larger than TASK_SIZE).
> >>So it can effect any non-MMU platform.
> >
> >Depending on how TASK_SIZE is defined - it looks like everyone else forces 
> >it to end of memory, except 68k[nommu].
> >
> >asm-arm/memory.h:#define TASK_SIZE              (CONFIG_DRAM_SIZE)
> >asm-blackfin/processor.h:#define TASK_SIZE      (memory_end)
> >asm-frv/mem-layout.h:#define TASK_SIZE                  __UL(0xFFFFFFFFUL)
> >
> >asm-m68k/processor.h:#define TASK_SIZE  (0xF0000000UL)
> >asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000)
> >asm-m68k/processor.h:#define TASK_SIZE  (0x0E000000UL)
> >asm-m68knommu/processor.h:#define TASK_SIZE     (0xF0000000UL)
> 
> Probably too:
> 
> asm-sh/processor.h:#define TASK_SIZE    0x7c000000UL
> 
> which has some parts with MMU.
> 
> There have been others out of tree that have it like this to.
> 
It would be at 0x80000000UL on SH if it weren't for address space area
limitations. The 0x7c000000 - 0x7fffffff space is used for shadowing P4
registers in the virtual address space (area 7) with the MMU and it's a
reserved area without the MMU, so TASK_SIZE is trimmed right before this.

However, I'm not sure that the patch Greg has in this set is sufficient
for the problem described. do_mmap_pgoff() won't allow a > TASK_SIZE
mapping anyways. In the SH case we certainly have address spaces that
can be given user permissions well above TASK_SIZE, area 7 space is used
as a bit of a hack for some of this in the MMU case..
-
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/