linux-kernel - Re: dm overlaybd: targets mapping OverlayBD image

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: <ZGz32yw7ecKhW+lj@redhat.com>
Date:   Tue, 23 May 2023 13:28:59 -0400
From:   Mike Snitzer <snitzer@...nel.org>
To:     Du Rui <durui@...ux.alibaba.com>
Cc:     dm-devel@...hat.com, linux-kernel@...r.kernel.org,
        Alasdair Kergon <agk@...hat.com>,
        Alexander Larsson <alexl@...hat.com>,
        Giuseppe Scrivano <gscrivan@...hat.com>
Subject: Re: dm overlaybd: targets mapping OverlayBD image

On Fri, May 19 2023 at  6:27P -0400,
Du Rui <durui@...ux.alibaba.com> wrote:

> OverlayBD is a novel layering block-level image format, which is design
> for container, secure container and applicable to virtual machine,
> published in USENIX ATC '20
> https://www.usenix.org/system/files/atc20-li-huiba.pdf
> 
> OverlayBD already has a ContainerD non-core sub-project implementation
> in userspace, as an accelerated container image service
> https://github.com/containerd/accelerated-container-image
> 
> It could be much more efficient when do decompressing and mapping works
> in the kernel with the framework of device-mapper, in many circumstances,
> such as secure container runtime, mobile-devices, etc.
> 
> This patch contains a module, dm-overlaybd, provides two kinds of targets
> dm-zfile and dm-lsmt, to expose a group of block-devices contains
> OverlayBD image as a overlaid read-only block-device.
> 
> Signed-off-by: Du Rui <durui@...ux.alibaba.com>

<snip, original patch here: [1] >

I appreciate that this work is being done with an eye toward
containerd "community" and standardization but based on my limited
research it appears that this format of OCI image storage/use is only
used by Alibaba? (but I could be wrong...)

But you'd do well to explain why the userspace solution isn't
acceptable. Are there security issues that moving the implementation
to kernel addresses?

I also have doubts that this solution is _actually_ more performant
than a proper filesystem based solution that allows page cache sharing
of container image data across multiple containers.

There is an active discussion about, and active development effort
for, using overlayfs + erofs for container images.  I'm reluctant to
merge this DM based container image approach without wider consensus
from other container stakeholders.

But short of reaching wider consensus on the need for these DM
targets: there is nothing preventing you from carrying these changes
in your alibaba kernel.

Mike

[1]: https://patchwork.kernel.org/project/dm-devel/patch/9505927dabc3b6695d62dfe1be371b12f5bdebf7.1684491648.git.durui@linux.alibaba.com/