From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "keescook@chromium.org" <keescook@chromium.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Yu, Yu-cheng" <yu-cheng.yu@intel.com>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
"ebiederm@xmission.com" <ebiederm@xmission.com>,
"Chatre, Reinette" <reinette.chatre@intel.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"Luck, Tony" <tony.luck@intel.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"Brown, Len" <len.brown@intel.com>
Subject: Re: [PATCH 3/3] elf: Don't write past end of notes for regset gap
Date: Tue, 15 Mar 2022 21:48:29 +0000 [thread overview]
Message-ID: <983f20076ae02f0b33d4609b19cb22ab379174f1.camel@intel.com> (raw)
In-Reply-To: <202203151329.0483BED@keescook>
On Tue, 2022-03-15 at 13:37 -0700, Kees Cook wrote:
> > /*
> > * Each other regset might generate a note too. For each
> > regset
> > - * that has no core_note_type or is inactive, we leave t-
> > >notes[i]
> > - * all zero and we'll know to skip writing it later.
> > + * that has no core_note_type or is inactive, skip it.
> > */
> > - for (i = 1; i < view->n; ++i) {
> > - const struct user_regset *regset = &view->regsets[i];
> > + note_iter = 1;
> > + for (view_iter = 1; view_iter < view->n; ++view_iter) {
> > + const struct user_regset *regset = &view-
> > >regsets[view_iter];
> > int note_type = regset->core_note_type;
> > bool is_fpreg = note_type == NT_PRFPREG;
> > void *data;
> > @@ -1800,10 +1800,11 @@ static int fill_thread_core_info(struct
> > elf_thread_core_info *t,
> > if (is_fpreg)
> > SET_PR_FPVALID(&t->prstatus);
> >
>
> info->thread_notes contains the count. Since fill_thread_core_info()
> passes a info member by reference, it might make sense to just pass
> info
> itself, then the size can be written and a bounds-check can be added
> here:
>
> if (WARN_ON_ONCE(i >= info->thread_notes))
> continue;
Hi Kees,
Thanks for the quick response.
Are you saying in addition to utilizing the allocation better, also
catch if the allocation is still too small? Or do this check instead of
the change in how to utilize the array, and then maintain the
restriction on having gaps in the regsets?
If it's the former, it seems a bit excessive since the allocation and
usage are only one function call away from each other and the logic is
now such that it can't overflow. I can add it if you want.
If it's to just warn on the gaps, it could also be done directly like:
/* Don't expect gaps in regset views */
WARN_ON(!regset->regset_get);
And it might be a little clearer of a hint about this expectation of
the arch's.
Let me know what you prefer and I can make the change.
next prev parent reply other threads:[~2022-03-15 21:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-15 20:17 [PATCH 0/3] Regset cleanups Rick Edgecombe
2022-03-15 20:17 ` [PATCH 1/3] x86: Separate out x86_regset for 32 and 64 bit Rick Edgecombe
2022-03-15 20:41 ` Kees Cook
2022-03-15 21:53 ` Edgecombe, Rick P
2022-03-16 2:48 ` Kees Cook
2022-03-16 19:06 ` Edgecombe, Rick P
2022-03-16 19:42 ` Edgecombe, Rick P
2022-03-16 19:43 ` Kees Cook
2022-03-15 23:01 ` Eric W. Biederman
2022-03-15 23:33 ` Edgecombe, Rick P
2022-03-15 20:17 ` [PATCH 2/3] x86: Improve formatting of user_regset arrays Rick Edgecombe
2022-03-15 20:38 ` Kees Cook
2022-03-15 21:48 ` Edgecombe, Rick P
2022-03-15 20:17 ` [PATCH 3/3] elf: Don't write past end of notes for regset gap Rick Edgecombe
2022-03-15 20:37 ` Kees Cook
2022-03-15 21:48 ` Edgecombe, Rick P [this message]
2022-03-16 2:48 ` 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=983f20076ae02f0b33d4609b19cb22ab379174f1.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=len.brown@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=reinette.chatre@intel.com \
--cc=tony.luck@intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yu-cheng.yu@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).