lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 20 Dec 2016 13:40:26 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     James Simmons <jsimmons@...radead.org>
Cc:     Kees Cook <keescook@...omium.org>, devel@...verdev.osuosl.org,
        Andreas Dilger <andreas.dilger@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        Bruno Faccini <bruno.faccini@...el.com>,
        Oleg Drokin <oleg.drokin@...el.com>,
        Vitaly Fertman <vitaly_fertman@...atex.com>,
        "John L. Hammond" <john.hammond@...el.com>,
        Bruce Korb <bruce.korb@...il.com>,
        Emoly Liu <emoly.liu@...el.com>, lustre-devel@...ts.lustre.org
Subject: Re: [PATCH] staging: lustre: ldlm: use designated initializers

On Mon, Dec 19, 2016 at 04:22:58PM +0000, James Simmons wrote:
> 
> > 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 <keescook@...omium.org>
> > ---
> >  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.

You've misunderstood.  The plugin just changes how the struct is laid
out, it doesn't put data into the struct.  So this is fine.

The places where it's not fine are when the layout is required because
it's shared with userspace or set by the hardware.

regards,
dan carpenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ