linux-kernel - RE: [PATCH 0/5] cramfs refresh for embedded usage

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:   Mon, 14 Aug 2017 14:17:02 -0400 (EDT)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Chris Brandt <Chris.Brandt@...esas.com>
cc:     Alexander 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 0/5] cramfs refresh for embedded usage

On Mon, 14 Aug 2017, Chris Brandt wrote:

> On Monday, August 14, 2017, Nicolas Pitre wrote:
> > > I just applied the patches tried this simple test:
> > >  - tested with a Renesas RZ/A1 (Cortex-A9...so it has an MMU).
> > >  - I set the sticky bit for busybox before using mkcramfs
> > 
> > You need the newer mkcramfs I linked to in the documentation. With it
> > you don't need to play tricks with the sticky bit anymore. However you
> > need to specify -X twice (or just once for no-MMU targets) and it will
> > make every ELF files XIPable automatically.
> 
> OK. Now I am getting bigger images that makes me think all the ELF files
> are uncompressed.

Yeah. No way around that of course. I listed a few TODO items to 
mitigate the alignment losses if you have many executables.

> > > However, at this point I'm not sure how I can confirm that the XIP
> > > busybox actually executed as XIP or not.
> > 
> > Just use busybox's built-in cat command and dump the content of
> > /proc/self/maps. You should see an offset that refers to a physical
> > address within your cramfs image for those segments marked read-only and
> > executable.
> 
> It works! Pretty cool.
> 
> $ /mnt/bin/busybox cat /proc/self/maps
> 00008000-000a1000 r-xp 1b005000 00:10 18192      /mnt/bin/busybox
> 
>   (my cramfs flash image is at physical address 0x1B000000)

Good!  Independent validation is always nice.

> However, now with your mkcramfs tool, I can no longer mount my cramfs 
> image as the rootfs on boot. I was able to do that before (ie, 30 minutes 
> ago) when using the community mkcramfs (ie, 30 minutes ago).
> 
> I get this:
> 
> [    1.712425] cramfs: checking physical address 0x1b000000 for linear cramfs image
> [    1.720531] cramfs: linear cramfs image appears to be 15744 KB in size
> [    1.728656] VFS: Mounted root (cramfs_physmem filesystem) readonly on device 0:12.
> [    1.737062] devtmpfs: mounted
> [    1.741139] Freeing unused kernel memory: 48K
> [    1.745545] This architecture does not have kernel memory protection.
> [    1.760381] Starting init: /sbin/init exists but couldn't execute it (error -22)
> [    1.769685] Starting init: /bin/sh exists but couldn't execute it (error -14)

Is /sbin/init a link to busybox?
I suppose it just boots if you do mkcramfs without -X?
If so could you share your non-working cramfs image with me?


Nicolas