[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpeguq2BH_4WQDb=eGkoVGOUVhNhMRicT4b_PN-t6FTBFUoQ@mail.gmail.com>
Date: Mon, 6 Feb 2023 20:32:16 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Amir Goldstein <amir73il@...il.com>
Cc: Alexander Larsson <alexl@...hat.com>, gscrivan@...hat.com,
brauner@...nel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, david@...morbit.com,
viro@...iv.linux.org.uk, Vivek Goyal <vgoyal@...hat.com>,
Josef Bacik <josef@...icpanda.com>,
Gao Xiang <hsiangkao@...ux.alibaba.com>,
Jingbo Xu <jefflexu@...ux.alibaba.com>
Subject: Re: [PATCH v3 0/6] Composefs: an opportunistically sharing verified
image filesystem
On Mon, 6 Feb 2023 at 18:16, Amir Goldstein <amir73il@...il.com> wrote:
> it's not overlay{erofs+erofs}
> it's overlay{erofs+ext4} (or another fs-verity [1] supporting fs)
> the lower layer is a mutable fs with /objects/ dir containing
> the blobs.
>
> The way to ensure the integrity of erofs is to setup dm-verity at
> erofs mount time.
>
> The way to ensure the integrity of the blobs is to store an fs-verity
> signature of each blob file in trusted.overlay.verify xattr on the
> metacopy and for overlayfs to enable fsverity on the blob file before
> allowing access to the lowerdata.
>
> At least this is my understanding of the security model.
So this should work out of the box, right?
Thanks,
Miklos
Powered by blists - more mailing lists