linux-kernel - RE: [PATCH v2 4/5] cramfs: add mmap support

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:   Thu, 31 Aug 2017 02:29:50 +0000
From:   Chris Brandt <Chris.Brandt@...esas.com>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
CC:     Al Viro <viro@...IV.linux.org.uk>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-embedded@...r.kernel.org" <linux-embedded@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 4/5] cramfs: add mmap support

On Tuesday, August 29, 2017, Chris Brandt wrote:
> On Tuesday, August 29, 2017, Nicolas Pitre wrote:
> > On Tue, 29 Aug 2017, Chris Brandt wrote:
> >
> > > On Monday, August 28, 2017, Nicolas Pitre wrote:
> > > > OK I moved the lock promotion right at the beginning _before_
> > validating
> > > > the split point. Also got a reference on the file to make sure that
> > > > hasn't changed too.
> > > >
> > > > > While we are at it, what happens if you mmap 120Kb, then munmap()
> > the
> > > > middle
> > > > > 40Kb.  Leaving two 40Kb VMAs with 40Kb gap between them, that is.
> > Will
> > > > your
> > > > > ->vm_private_data be correct for both?
> > > >
> > > > It wouldn't, but I now changed it to contain absolute values so now
> it
> > > > will. And if the split point lands in the hole then the code just
> > > > readjusts the pgoff at the beginning of the remaining part.
> > > >
> > > > Here's the revised patch:
> > >
> > >
> > > For whatever it's worth, as soon as I moved to 4.13-rc7,
> > > CONFIG_CRAMFS_PHYSMEM=y crashes my XIP_KERNEL system before it can
> even
> > > get to any console output.
> > >
> > > (both the old patch and the new patch)
> > >
> > > If CONFIG_CRAMFS_PHYSMEM is not set, my XIP system boots fine.
> > >
> > > However, if I boot -rc7 as a uImage, the new patch works just as good
> as
> > > the old patch.
> >
> > When not a uImage, do you mean by that a XIP kernel?
> 
> Yes, CONFIG_XIP_KERNEL.
> 
> > If so you should
> > know by now from that other thread on LAK that the XIP linker script is
> > broken and probably just worked by luck till now. Still, if you could
> > bisect between -rc4 and -rc7 and pinpoint the change that makes it not
> > work that would be better than speculations.
> 
> Note that everything else seem OK when CONFIG_XIP_KERNEL=y. It's just
> when CONFIG_XIP_KERNEL=y CONFIG_CRAMFS_PHYSMEM=y which is odd. So
> hopefully
> that means it will be easy to track down.


Update:

My issue was caused by the XIP linker script (vmlinux-xip.lds.S).

Therefore, by applying the following patch series from the 
linux-arm-kernel mailing list, my system could boot normally.

 [PATCH v2 0/5] make XIP kernel .data compressed in ROM
 [PATCH v2 1/5] ARM: head-common.S: speed up startup code
 [PATCH v2 2/5] ARM: vmlinux*.lds.S: some decruftification
 [PATCH v2 3/5] ARM: vmlinux.lds.S: replace open coded .data sections with generic macros
 [PATCH v2 4/5] ARM: vmlinux-xip.lds.S: fix multiple issues
 [PATCH v2 5/5] ARM: XIP kernel: store .data compressed in ROM


Now that I could boot again, this cramfs series of patches operates as 
designed.

Notice that busybox, libc and ld have physical addresses in Flash (ie, XIP)

$ cat /proc/self/maps
00008000-000a1000 r-xp 1b005000 00:0c 18192      /bin/busybox
000a9000-000aa000 rw-p 00099000 00:0c 18192      /bin/busybox
000aa000-000ac000 rw-p 00000000 00:00 0          [heap]
b6eed000-b6fc6000 r-xp 1b0bc000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6fc6000-b6fce000 ---p 1b195000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6fce000-b6fd0000 r--p 000d9000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6fd0000-b6fd1000 rw-p 000db000 00:0c 766540     /lib/libc-2.18-2013.10.so
b6fd1000-b6fd4000 rw-p 00000000 00:00 0
b6fd4000-b6feb000 r-xp 1b0a4000 00:0c 670372     /lib/ld-2.18-2013.10.so
b6fee000-b6fef000 rw-p 00000000 00:00 0
b6ff0000-b6ff2000 rw-p 00000000 00:00 0
b6ff2000-b6ff3000 r--p 00016000 00:0c 670372     /lib/ld-2.18-2013.10.so
b6ff3000-b6ff4000 rw-p 00017000 00:0c 670372     /lib/ld-2.18-2013.10.so
bee27000-bee48000 rw-p 00000000 00:00 0          [stack]
beea4000-beea5000 r-xp 00000000 00:00 0          [sigpage]
ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]



Tested-by: Chris Brandt <chris.brandt@...esas.com>