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]

Message-ID: <SG2PR06MB116563FCF10E2615C65080F28A8C0@SG2PR06MB1165.apcprd06.prod.outlook.com>
Date:   Mon, 14 Aug 2017 18:01:54 +0000
From:   Chris Brandt <Chris.Brandt@...esas.com>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
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 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.


> > 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)




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)
[    1.776956] Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
[    1.791192] CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-rc1-00014-g53182a0b7245 #667
[    1.798959] Hardware name: Generic R7S72100 (Flattened Device Tree)
[    1.805519] [<bf809261>] (unwind_backtrace) from [<bf807aa3>] (show_stack+0xb/0xc)
[    1.813228] [<bf807aa3>] (show_stack) from [<bf810a1b>] (panic+0x6f/0x18c)
[    1.820163] [<bf810a1b>] (panic) from [<bfa9f067>] (kernel_init+0x6b/0x98)
[    1.827078] [<bfa9f067>] (kernel_init) from [<bf805011>] (ret_from_fork+0x11/0x20)
[    1.834747] ---[ end Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.


Chris