From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761292AbcLSRLY (ORCPT ); Mon, 19 Dec 2016 12:11:24 -0500 Received: from casper.infradead.org ([85.118.1.10]:51248 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756481AbcLSRLV (ORCPT ); Mon, 19 Dec 2016 12:11:21 -0500 Date: Mon, 19 Dec 2016 17:11:18 +0000 (GMT) From: James Simmons To: Patrick Farrell cc: Kees Cook , "devel@driverdev.osuosl.org" , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Oleg Drokin , Vitaly Fertman , Bruce Korb , Emoly Liu , "lustre-devel@lists.lustre.org" Subject: Re: [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers In-Reply-To: Message-ID: References: <20161217010045.GA140343@beast>, User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1985284609-326501077-1482167478=:25173" X-Spam-Note: CRM114 invocation failed X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.4.1 on casper.infradead.org summary: Content analysis details: (-1.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 NO_RELAYS Informational: message was not relayed via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1985284609-326501077-1482167478=:25173 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT > James, > > > This should be a purely syntactical change, to help out tools - for GCC, I'm pretty sure the meaning of { > } and { NULL } are the same.  Also, I don't think struct randomization does what you're thinking. Yep. I misread his commit message. That is why it didn't make sense to me. > Is there anything written up on kernel struct randomization?  I was trying to find a talk/post from you or > something from LWN, but I couldn't find something about this specifically.  (Probably because I can't find > it among the other stuff that's been written up) > > > - Patrick > > __________________________________________________________________________________________________________ > From: lustre-devel on behalf of James Simmons > > Sent: Monday, December 19, 2016 10:22:58 AM > To: Kees Cook > Cc: devel@driverdev.osuosl.org; Greg Kroah-Hartman; linux-kernel@vger.kernel.org; Oleg Drokin; Vitaly > Fertman; Bruce Korb; Emoly Liu; lustre-devel@lists.lustre.org > Subject: Re: [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers   > > > Prepare to mark sensitive kernel structures for randomization by making > > sure they're using designated initializers. These were identified during > > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > > extracted from grsecurity. > > > > Signed-off-by: Kees Cook > > --- > >  drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 2 +- > >  1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c > b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c > > index 722160784f83..f815827532dc 100644 > > --- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c > > +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c > > @@ -143,7 +143,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req, __u64 *flags, > >        int added = (mode == LCK_NL); > >        int overlaps = 0; > >        int splitted = 0; > > -     const struct ldlm_callback_suite null_cbs = { NULL }; > > +     const struct ldlm_callback_suite null_cbs = { }; > >  > >        CDEBUG(D_DLMTRACE, > >               "flags %#llx owner %llu pid %u mode %u start %llu end %llu\n", > > Nak. Filling null_cbs with random data is a bad idea. If you look at > ldlm_lock_create() where this is used you have > > if (cbs) { >         lock->l_blocking_ast = cbs->lcs_blocking; >         lock->l_completion_ast = cbs->lcs_completion; >         lock->l_glimpse_ast = cbs->lcs_glimpse; > } > > Having lock->l_* point to random addresses is a bad idea. > What really needs to be done is proper initialization of that > structure. A bunch of patches will be coming to address this. > _______________________________________________ > lustre-devel mailing list > lustre-devel@lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org > > --1985284609-326501077-1482167478=:25173--