From: "Darrick J. Wong" <djwong@kernel.org>
To: Eryu Guan <eguan@linux.alibaba.com>
Cc: Jakob Unterwurzacher <jakobunt@gmail.com>,
Eryu Guan <guan@eryu.me>,
fstests@vger.kernel.org
Subject: Re: [PATCH] generic/286: fix integer underflow on block sizes != 4096
Date: Tue, 25 May 2021 20:41:39 -0700 [thread overview]
Message-ID: <20210526034139.GL202095@locust> (raw)
In-Reply-To: <20210526032037.GF60846@e18g06458.et15sqa>
On Wed, May 26, 2021 at 11:20:37AM +0800, Eryu Guan wrote:
> On Tue, May 25, 2021 at 07:34:14PM +0200, Jakob Unterwurzacher wrote:
> > On Sun, May 23, 2021 at 11:05 AM Eryu Guan <guan@eryu.me> wrote:
> > > The total read length should be
> > >
> > > "The length of this extent is (hole_off - data_off)"
> > >
> > > according to the comments above do_extent_copy(). Total read length
> > > being not a multiple of 4k means 'data_off' or 'hole_off' is not 4k
> > > aligned.
> >
> > That is correct.
> >
> > > But generic/286 creates source files with length of all data extents and
> > > hole extents being multiple of 4k. So I still don't understand why this
> > > is valid for gocryptfs. Shouldn't that be a bug in seek_data/seek_hole
> > > in gocryptfs? Could you please elaborate?
> >
> > Yes sure, the situation is a bit complicated. gocryptfs works similar
> > to eCryptFS and EncFS (also overlay filesystems).
> > The files are stored in encrypted form in regular files on ext4 or xfs
> > or whatever "real disk" filesystem.
> > Disk space allocation & file holes are handled by the real filesystem.
> > A gocryptfs mount shows a decrypted view of these files.
> >
> > Now, gocryptfs uses AES-GCM for encryption. This adds 32 bytes of
> > overhead to every 4096-byte block,
> > which gives a storage size of 4128 bytes.
>
> Ah, that makes sense to me now. Would you please include the detailed
> explaination in commit log as well?
...and maybe a sample output of a seek_data/seek_hole scan between a
gocryptfs file and the ext4fs underneath it? I'm still trying to wrap
my head around what the problem here is.
It might also help to describe where the 32 bytes of overhead goes --
are you interleaving the overhead inline with 4k of encrypted content?
--D
>
> Thanks,
> Eryu
>
> >
> > The encryption overhead is why the files & holes created by
> > generic/286 are not 4k-aligned on disk when viewed through the
> > gocryptfs mount.
> >
> > Thanks, Jakob
next prev parent reply other threads:[~2021-05-26 3:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-22 18:48 [PATCH] generic/286: fix integer underflow on block sizes != 4096 Jakob Unterwurzacher
2021-05-23 9:05 ` Eryu Guan
2021-05-25 17:34 ` Jakob Unterwurzacher
2021-05-26 3:20 ` Eryu Guan
2021-05-26 3:41 ` Darrick J. Wong [this message]
2021-05-26 8:02 ` Jakob Unterwurzacher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210526034139.GL202095@locust \
--to=djwong@kernel.org \
--cc=eguan@linux.alibaba.com \
--cc=fstests@vger.kernel.org \
--cc=guan@eryu.me \
--cc=jakobunt@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.