From: Mike Rapoport <rppt@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Mike Rapoport <rppt@linux.ibm.com>,
Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH] sched: fix build with GCC_PLUGIN_RANDSTRUCT
Date: Sun, 28 Jun 2020 09:44:03 +0300 [thread overview]
Message-ID: <20200628064403.GA576120@kernel.org> (raw)
In-Reply-To: <20200627181214.3a4d4a42@oasis.local.home>
On Sat, Jun 27, 2020 at 06:12:14PM -0400, Steven Rostedt wrote:
> On Sat, 20 Jun 2020 13:41:36 +0300
> Mike Rapoport <rppt@kernel.org> wrote:
>
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > Since the commit a148866489fb ("sched: Replace rq::wake_list")
> > task_struct and CSD_TYPE_TTWU objects can be on the same queue and this
> > requires that have "layout similar enough".
> >
> > This assumption is broken when CONFIG_GCC_PLUGIN_RANDSTRUCT is enabled:
>
> You forgot to Cc Kees, who's the one that is probably the most
> concerned about randomizing structures!
I was not concerned about randomizing, I was troubled by failing
allyesconfig builds :)
> > /*
> > * This begins the randomizable portion of task_struct. Only
> > * scheduling-critical items should be added above here.
> > @@ -654,8 +663,6 @@ struct task_struct {
> > unsigned int ptrace;
> >
> > #ifdef CONFIG_SMP
> > - struct llist_node wake_entry;
> > - unsigned int wake_entry_type;
>
> What about instead just create an anonymous structure of the two. That
> way they can still be randomized within the task struct and not be a
> target of attacks?
>
> struct {
> struct llist_node wake_entry;
> unsigned int wake_entry_type;
> };
>
> Would that work?
Yep, thanks, this works.
Will send v2 soon.
> -- Steve
>
>
> > int on_cpu;
> > #ifdef CONFIG_THREAD_INFO_IN_TASK
> > /* Current CPU: */
>
--
Sincerely yours,
Mike.
prev parent reply other threads:[~2020-06-28 6:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-20 10:41 [PATCH] sched: fix build with GCC_PLUGIN_RANDSTRUCT Mike Rapoport
2020-06-24 10:20 ` Mike Rapoport
2020-06-27 22:12 ` Steven Rostedt
2020-06-28 6:44 ` Mike Rapoport [this message]
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=20200628064403.GA576120@kernel.org \
--to=rppt@kernel.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=rppt@linux.ibm.com \
--cc=vincent.guittot@linaro.org \
/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.