All of lore.kernel.org
 help / color / mirror / Atom feed
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.

      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.