From: Eric Biggers <ebiggers@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: David Howells <dhowells@redhat.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
linux-hardening@vger.kernel.org, keyrings@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] big_keys: Use struct for internal payload
Date: Mon, 9 May 2022 16:13:48 -0700 [thread overview]
Message-ID: <YnmgLLcJfPRKEYuk@sol.localdomain> (raw)
In-Reply-To: <20220508175732.2693426-1-keescook@chromium.org>
On Sun, May 08, 2022 at 10:57:31AM -0700, Kees Cook wrote:
> The randstruct GCC plugin gets upset when it sees struct path (which is
> randomized) being assigned from a "void *" (which it cannot type-check).
>
> There's no need for these casts, as the entire internal payload use is
> following a normal struct layout. Convert the enum-based void * offset
> dereferencing to the new big_key_payload struct. No meaningful machine
> code changes result after this change, and source readability is improved.
>
> Drop the randstruct exception now that there is no "confusing" cross-type
> assignment.
>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: linux-hardening@vger.kernel.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> scripts/gcc-plugins/randomize_layout_plugin.c | 2 -
> security/keys/big_key.c | 64 ++++++++++---------
> 2 files changed, 34 insertions(+), 32 deletions(-)
This looks fine to me, although the way that an array of void pointers is cast
to/from another struct is still weird. I'd prefer if the payload was just
changed into a separate allocation.
A couple nits below if you stay with your proposed solution:
> void big_key_free_preparse(struct key_preparsed_payload *prep)
> {
> + struct big_key_payload *payload = to_big_key_payload(prep->payload);
> +
> if (prep->datalen > BIG_KEY_FILE_THRESHOLD) {
> - struct path *path = (struct path *)&prep->payload.data[big_key_path];
> + struct path *path = &payload->path;
>
> path_put(path);
> }
This could just do:
if (prep->datalen > BIG_KEY_FILE_THRESHOLD)
path_put(&payload->path);
> void big_key_destroy(struct key *key)
> {
> - size_t datalen = (size_t)key->payload.data[big_key_len];
> + struct big_key_payload *payload = to_big_key_payload(key->payload);
>
> - if (datalen > BIG_KEY_FILE_THRESHOLD) {
> - struct path *path = (struct path *)&key->payload.data[big_key_path];
> + if (payload->length > BIG_KEY_FILE_THRESHOLD) {
> + struct path *path = &payload->path;
>
> path_put(path);
> path->mnt = NULL;
> path->dentry = NULL;
> }
And similarly:
if (payload->length > BIG_KEY_FILE_THRESHOLD) {
path_put(&payload->path);
payload->path.mnt = NULL;
payload->path.dentry = NULL;
}
- Eric
next prev parent reply other threads:[~2022-05-09 23:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-08 17:57 [PATCH] big_keys: Use struct for internal payload Kees Cook
2022-05-09 23:13 ` Eric Biggers [this message]
2022-05-10 22:18 ` Kees Cook
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=YnmgLLcJfPRKEYuk@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=dhowells@redhat.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=serge@hallyn.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.