linux-kernel - Re: [PATCH 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]

Message-ID: <alpine.LFD.2.20.1708132144080.17016@knanqh.ubzr>
Date:   Sun, 13 Aug 2017 22:29:09 -0400 (EDT)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Christoph Hellwig <hch@...radead.org>
cc:     Alexander Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel@...r.kernel.org, linux-embedded@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Chris Brandt <Chris.Brandt@...esas.com>
Subject: Re: [PATCH 1/5] cramfs: direct memory access support

On Sat, 12 Aug 2017, Christoph Hellwig wrote:

> Direct physical memory access in a file system is never safe.
> Please make sure this goes through struct dax_operations.

Well, after having a closer look, I don't think dax might be relevant 
here for a couple reasons:

- cramfs is read-only. No concurrent writes to worry about. Please 
  elaborate if you have other safety concerns in mind.

- This series targets small no-MMU systems. There is no paging involved 
  given the lack of a MMU. The whole of the filesystem is always 
  directly accessible in the address space from ROM alongside with the 
  actual kernel code being executed. I don't see how dax would ever be 
  pertinent here.

- Even with MMU systems, the maximum size of a cramfs image can't exceed 
  272MB. In practice it is likely to be much much less. Given this 
  targets small memory systems, there is always plenty of vmalloc space 
  left to map it all and even a 272MB memremap() wouldn't be a problem.  
  If it is a problem then maybe your system has large resources to 
  manage already and you're pretty unlikely to be using cramfs in the 
  first place, otherwise accessing it through a block device would be 
  just fine, at which point you'd better consider squashfs instead of 
  this.

All this to say that I think that dax is _way_ overkill and 
inappropriate for the intended cramfs use case this series is 
addressing.


Nicolas