linux-kernel - RE: [PATCH v4 1/5] cramfs: direct memory access 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:   Tue, 3 Oct 2017 14:58:57 +0000
From:   Chris Brandt <Chris.Brandt@...esas.com>
To:     Rob Herring <robh@...nel.org>,
        Christoph Hellwig <hch@...radead.org>
CC:     Nicolas Pitre <nicolas.pitre@...aro.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "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>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: RE: [PATCH v4 1/5] cramfs: direct memory access support

On Tuesday, October 03, 2017 1, Rob Herring wrote:
> On Sun, Oct 1, 2017 at 3:29 AM, Christoph Hellwig <hch@...radead.org>
> wrote:
> > On Wed, Sep 27, 2017 at 07:32:20PM -0400, Nicolas Pitre wrote:
> >> To distinguish between both access types, the cramfs_physmem filesystem
> >> type must be specified when using a memory accessible cramfs image, and
> >> the physaddr argument must provide the actual filesystem image's
> physical
> >> memory location.
> >
> > Sorry, but this still is a complete no-go.  A physical address is not a
> > proper interface.  You still need to have some interface for your NOR
> nand
> > or DRAM.  - usually that would be a mtd driver, but if you have a good
> > reason why that's not suitable for you (and please explain it well)
> > we'll need a little OF or similar layer to bind a thin driver.
> 
> I don't disagree that we may need DT binding here, but DT bindings are
> h/w description and not a mechanism bind Linux kernel drivers. It can
> be a subtle distinction, but it is an important one.
> 
> I can see the case where we have no driver. For RAM we don't have a
> driver, yet pretty much all hardware has a DRAM controller which we
> just rely on the firmware to setup. I could also envision that we have
> hardware we do need to configure in the kernel. Perhaps the boot
> settings are not optimal or we want/need to manage the clocks. That
> seems somewhat unlikely if the kernel is also XIP from the same flash
> as it is in Nico's case.
> 
> We do often describe the flash layout in DT when partitions are not
> discoverable. I don't know if that would be needed here. Would the ROM
> here ever be updateable from within Linux? If we're talking about a
> single address to pass the kernel, DT seems like an overkill and
> kernel cmdline is perfectly valid IMO.


As someone that's been using an XIP File system for a while now (AXFS, 
obviously not xip-cramfs), there is a way (in my system at least) to 
write to the same Flash that the kernel and file system are currently XIP 
executing (think jumping to RAM, doing a small flash operation, then 
jumping back to Flash).

The use case is if you've logically partitioned your flash such that you
keep your application in a separate file XIP filesystem image, you 
remotely download an updated version to some unused portion of Flash, then 
simply unmount what you have been using and mount the new image since you
can pass in the physical address of where you wrote your new image to.

So in that case, I guess you can do some type of DT overlay or 
something, but at the moment, just having the physical address as a parameter in 
mount command makes it pretty darn easy.

Chris