From: Eric Biggers <ebiggers@google.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-fsdevel@vger.kernel.org, jaegeuk@kernel.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] fscrypto: move ioctl processing more fully into common code
Date: Sat, 26 Nov 2016 20:20:48 -0800 [thread overview]
Message-ID: <20161127042048.GA34163@google.com> (raw)
In-Reply-To: <20161127000901.wuyl6t6wp6qhmkrs@thunk.org>
On Sat, Nov 26, 2016 at 07:09:01PM -0500, Theodore Ts'o wrote:
> On Mon, Oct 17, 2016 at 09:54:06AM -0700, Eric Biggers wrote:
> > In addition, make the common functions do the copies to and from
> > userspace rather than duplicating this code within each filesystem, and
> > memset the policy to 0 to make it clear there is no stack leak.
>
> I don't see any point of doing this, given that we initialize all
> parts of the fscrypt_policy structure; and since this structure is
> part of UAPI, we can't change it without breaking userspace.
>
> I'll apply this with the memset (and the above comment in the commit
> description) removed.
>
> - Ted
I guess I'm okay with that, since struct fscrypt_policy won't have any padding
bytes because its members are all bytes. Plus it's marked __packed, though I
think that was a mistake given that the struct isn't stored on disk directly.
Eric
------------------------------------------------------------------------------
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@google.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, jaegeuk@kernel.org
Subject: Re: [PATCH] fscrypto: move ioctl processing more fully into common code
Date: Sat, 26 Nov 2016 20:20:48 -0800 [thread overview]
Message-ID: <20161127042048.GA34163@google.com> (raw)
In-Reply-To: <20161127000901.wuyl6t6wp6qhmkrs@thunk.org>
On Sat, Nov 26, 2016 at 07:09:01PM -0500, Theodore Ts'o wrote:
> On Mon, Oct 17, 2016 at 09:54:06AM -0700, Eric Biggers wrote:
> > In addition, make the common functions do the copies to and from
> > userspace rather than duplicating this code within each filesystem, and
> > memset the policy to 0 to make it clear there is no stack leak.
>
> I don't see any point of doing this, given that we initialize all
> parts of the fscrypt_policy structure; and since this structure is
> part of UAPI, we can't change it without breaking userspace.
>
> I'll apply this with the memset (and the above comment in the commit
> description) removed.
>
> - Ted
I guess I'm okay with that, since struct fscrypt_policy won't have any padding
bytes because its members are all bytes. Plus it's marked __packed, though I
think that was a mistake given that the struct isn't stored on disk directly.
Eric
next prev parent reply other threads:[~2016-11-27 4:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-17 16:54 [PATCH] fscrypto: move ioctl processing more fully into common code Eric Biggers
2016-10-17 16:54 ` Eric Biggers
2016-10-18 12:22 ` Richard Weinberger
2016-10-18 16:52 ` Eric Biggers
2016-11-22 23:15 ` Eric Biggers
2016-11-27 0:09 ` Theodore Ts'o
2016-11-27 0:09 ` Theodore Ts'o
2016-11-27 4:20 ` Eric Biggers [this message]
2016-11-27 4:20 ` Eric Biggers
2016-11-27 17:39 ` Theodore Ts'o
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=20161127042048.GA34163@google.com \
--to=ebiggers@google.com \
--cc=jaegeuk@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
/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.