* [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-17 1:00 ` Kees Cook 0 siblings, 0 replies; 35+ messages in thread From: Kees Cook @ 2016-12-17 1:00 UTC (permalink / raw) To: linux-kernel Cc: Oleg Drokin, Andreas Dilger, James Simmons, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Bruce Korb, lustre-devel, devel 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@chromium.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", -- 2.7.4 -- Kees Cook Nexus Security ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-17 1:00 ` Kees Cook 0 siblings, 0 replies; 35+ messages in thread From: Kees Cook @ 2016-12-17 1:00 UTC (permalink / raw) To: linux-kernel Cc: Oleg Drokin, Andreas Dilger, James Simmons, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Bruce Korb, lustre-devel, devel 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@chromium.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", -- 2.7.4 -- Kees Cook Nexus Security ^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-17 1:00 ` [lustre-devel] " Kees Cook @ 2016-12-19 16:22 ` James Simmons -1 siblings, 0 replies; 35+ messages in thread From: James Simmons @ 2016-12-19 16:22 UTC (permalink / raw) To: Kees Cook Cc: linux-kernel, Oleg Drokin, Andreas Dilger, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Bruce Korb, lustre-devel, devel > 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@chromium.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. 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-19 16:22 ` James Simmons 0 siblings, 0 replies; 35+ messages in thread From: James Simmons @ 2016-12-19 16:22 UTC (permalink / raw) To: Kees Cook Cc: linux-kernel, Oleg Drokin, Andreas Dilger, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Bruce Korb, lustre-devel, devel > 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@chromium.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. 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-19 16:22 ` [lustre-devel] " James Simmons @ 2016-12-19 16:48 ` Bruce Korb -1 siblings, 0 replies; 35+ messages in thread From: Bruce Korb @ 2016-12-19 16:47 UTC (permalink / raw) To: James Simmons Cc: Kees Cook, Linux Kernel Mailing List, Oleg Drokin, Andreas Dilger, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Lustre Development List, devel On Mon, Dec 19, 2016 at 8:22 AM, James Simmons >> --- 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. I'm not understanding the effect of the original difference. If you specify any initializer, then all fields not specified are filled with zero bits. Any pointers are, perforce, NULL. That should make both "{ NULL }" and "{}" equivalent. Maybe a worthwhile change would be to: static const struct ldlm_callback_suite null_cbs; then it is not even necessary to specify an initializer. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-19 16:48 ` Bruce Korb 0 siblings, 0 replies; 35+ messages in thread From: Bruce Korb @ 2016-12-19 16:48 UTC (permalink / raw) To: James Simmons Cc: Kees Cook, Linux Kernel Mailing List, Oleg Drokin, Andreas Dilger, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Lustre Development List, devel On Mon, Dec 19, 2016 at 8:22 AM, James Simmons >> --- 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. I'm not understanding the effect of the original difference. If you specify any initializer, then all fields not specified are filled with zero bits. Any pointers are, perforce, NULL. That should make both "{ NULL }" and "{}" equivalent. Maybe a worthwhile change would be to: static const struct ldlm_callback_suite null_cbs; then it is not even necessary to specify an initializer. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-19 16:48 ` [lustre-devel] " Bruce Korb @ 2016-12-19 17:12 ` James Simmons -1 siblings, 0 replies; 35+ messages in thread From: James Simmons @ 2016-12-19 17:12 UTC (permalink / raw) To: Bruce Korb Cc: Kees Cook, Linux Kernel Mailing List, Oleg Drokin, Andreas Dilger, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Lustre Development List, devel > On Mon, Dec 19, 2016 at 8:22 AM, James Simmons > >> --- 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. > > I'm not understanding the effect of the original difference. If you > specify any initializer, then all fields not specified are filled with > zero bits. Any pointers are, perforce, NULL. That should make both "{ > NULL }" and "{}" equivalent. Maybe a worthwhile change would be to: > > static const struct ldlm_callback_suite null_cbs; I perfer this as well. > then it is not even necessary to specify an initializer. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-19 17:12 ` James Simmons 0 siblings, 0 replies; 35+ messages in thread From: James Simmons @ 2016-12-19 17:12 UTC (permalink / raw) To: Bruce Korb Cc: Kees Cook, Linux Kernel Mailing List, Oleg Drokin, Andreas Dilger, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Lustre Development List, devel > On Mon, Dec 19, 2016 at 8:22 AM, James Simmons > >> --- 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. > > I'm not understanding the effect of the original difference. If you > specify any initializer, then all fields not specified are filled with > zero bits. Any pointers are, perforce, NULL. That should make both "{ > NULL }" and "{}" equivalent. Maybe a worthwhile change would be to: > > static const struct ldlm_callback_suite null_cbs; I perfer this as well. > then it is not even necessary to specify an initializer. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-19 16:48 ` [lustre-devel] " Bruce Korb @ 2016-12-20 7:10 ` Dan Carpenter -1 siblings, 0 replies; 35+ messages in thread From: Dan Carpenter @ 2016-12-20 7:10 UTC (permalink / raw) To: Bruce Korb Cc: James Simmons, devel, Andreas Dilger, Kees Cook, Greg Kroah-Hartman, Linux Kernel Mailing List, Bruno Faccini, Oleg Drokin, Vitaly Fertman, John L. Hammond, Emoly Liu, Lustre Development List On Mon, Dec 19, 2016 at 08:47:50AM -0800, Bruce Korb wrote: > On Mon, Dec 19, 2016 at 8:22 AM, James Simmons > >> --- 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. > > I'm not understanding the effect of the original difference. If you > specify any initializer, then all fields not specified are filled with > zero bits. Any pointers are, perforce, NULL. That should make both "{ > NULL }" and "{}" equivalent. They are equivalent, yes, but people want to use a GCC plugin that randomizes struct layouts for internal structures and the plugin doesn't work when you use struct ordering to initialize the struct. The plugin requires that you use designated intializers. regards, dan carpenter ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-20 7:10 ` Dan Carpenter 0 siblings, 0 replies; 35+ messages in thread From: Dan Carpenter @ 2016-12-20 7:10 UTC (permalink / raw) To: Bruce Korb Cc: James Simmons, devel, Andreas Dilger, Kees Cook, Greg Kroah-Hartman, Linux Kernel Mailing List, Bruno Faccini, Oleg Drokin, Vitaly Fertman, John L. Hammond, Emoly Liu, Lustre Development List On Mon, Dec 19, 2016 at 08:47:50AM -0800, Bruce Korb wrote: > On Mon, Dec 19, 2016 at 8:22 AM, James Simmons > >> --- 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. > > I'm not understanding the effect of the original difference. If you > specify any initializer, then all fields not specified are filled with > zero bits. Any pointers are, perforce, NULL. That should make both "{ > NULL }" and "{}" equivalent. They are equivalent, yes, but people want to use a GCC plugin that randomizes struct layouts for internal structures and the plugin doesn't work when you use struct ordering to initialize the struct. The plugin requires that you use designated intializers. regards, dan carpenter ^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-20 7:10 ` [lustre-devel] " Dan Carpenter @ 2016-12-20 14:57 ` Hammond, John -1 siblings, 0 replies; 35+ messages in thread From: Hammond, John @ 2016-12-20 14:57 UTC (permalink / raw) To: Dan Carpenter, Bruce Korb Cc: James Simmons, devel, Dilger, Andreas, Kees Cook, Greg Kroah-Hartman, Linux Kernel Mailing List, Faccini, Bruno, Drokin, Oleg, Vitaly Fertman, Liu, Emoly, Lustre Development List > On Mon, Dec 19, 2016 at 08:47:50AM -0800, Bruce Korb wrote: > > On Mon, Dec 19, 2016 at 8:22 AM, James Simmons > > >> --- 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. > > > > I'm not understanding the effect of the original difference. If you > > specify any initializer, then all fields not specified are filled with > > zero bits. Any pointers are, perforce, NULL. That should make both "{ > > NULL }" and "{}" equivalent. > > They are equivalent, yes, but people want to use a GCC plugin that randomizes > struct layouts for internal structures and the plugin doesn't work when you use > struct ordering to initialize the struct. The plugin requires that you use > designated intializers. "{ NULL }" is valid ISO C, but unfortunately "{}" is not. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-20 14:57 ` Hammond, John 0 siblings, 0 replies; 35+ messages in thread From: Hammond, John @ 2016-12-20 14:57 UTC (permalink / raw) To: Dan Carpenter, Bruce Korb Cc: James Simmons, devel, Dilger, Andreas, Kees Cook, Greg Kroah-Hartman, Linux Kernel Mailing List, Faccini, Bruno, Drokin, Oleg, Vitaly Fertman, Liu, Emoly, Lustre Development List > On Mon, Dec 19, 2016 at 08:47:50AM -0800, Bruce Korb wrote: > > On Mon, Dec 19, 2016 at 8:22 AM, James Simmons > > >> --- 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. > > > > I'm not understanding the effect of the original difference. If you > > specify any initializer, then all fields not specified are filled with > > zero bits. Any pointers are, perforce, NULL. That should make both "{ > > NULL }" and "{}" equivalent. > > They are equivalent, yes, but people want to use a GCC plugin that randomizes > struct layouts for internal structures and the plugin doesn't work when you use > struct ordering to initialize the struct. The plugin requires that you use > designated intializers. "{ NULL }" is valid ISO C, but unfortunately "{}" is not. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-20 14:57 ` [lustre-devel] " Hammond, John @ 2016-12-20 16:48 ` Bruce Korb -1 siblings, 0 replies; 35+ messages in thread From: Bruce Korb @ 2016-12-20 16:47 UTC (permalink / raw) To: Hammond, John Cc: Dan Carpenter, James Simmons, devel, Dilger, Andreas, Kees Cook, Greg Kroah-Hartman, Linux Kernel Mailing List, Faccini, Bruno, Drokin, Oleg, Vitaly Fertman, Liu, Emoly, Lustre Development List > > "{ NULL }" is valid ISO C, but unfortunately "{}" is not. Just make the thing "static const" and don't use an initializer. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-20 16:48 ` Bruce Korb 0 siblings, 0 replies; 35+ messages in thread From: Bruce Korb @ 2016-12-20 16:48 UTC (permalink / raw) To: Hammond, John Cc: Dan Carpenter, James Simmons, devel, Dilger, Andreas, Kees Cook, Greg Kroah-Hartman, Linux Kernel Mailing List, Faccini, Bruno, Drokin, Oleg, Vitaly Fertman, Liu, Emoly, Lustre Development List > > "{ NULL }" is valid ISO C, but unfortunately "{}" is not. Just make the thing "static const" and don't use an initializer. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-20 16:48 ` [lustre-devel] " Bruce Korb @ 2016-12-20 18:52 ` Dan Carpenter -1 siblings, 0 replies; 35+ messages in thread From: Dan Carpenter @ 2016-12-20 18:52 UTC (permalink / raw) To: Bruce Korb Cc: Hammond, John, James Simmons, devel, Dilger, Andreas, Kees Cook, Greg Kroah-Hartman, Linux Kernel Mailing List, Faccini, Bruno, Drokin, Oleg, Vitaly Fertman, Liu, Emoly, Lustre Development List On Tue, Dec 20, 2016 at 08:47:51AM -0800, Bruce Korb wrote: > > > > "{ NULL }" is valid ISO C, but unfortunately "{}" is not. > > Just make the thing "static const" and don't use an initializer. That also works, of course. regards, dan carpenter ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-20 18:52 ` Dan Carpenter 0 siblings, 0 replies; 35+ messages in thread From: Dan Carpenter @ 2016-12-20 18:52 UTC (permalink / raw) To: Bruce Korb Cc: Hammond, John, James Simmons, devel, Dilger, Andreas, Kees Cook, Greg Kroah-Hartman, Linux Kernel Mailing List, Faccini, Bruno, Drokin, Oleg, Vitaly Fertman, Liu, Emoly, Lustre Development List On Tue, Dec 20, 2016 at 08:47:51AM -0800, Bruce Korb wrote: > > > > "{ NULL }" is valid ISO C, but unfortunately "{}" is not. > > Just make the thing "static const" and don't use an initializer. That also works, of course. regards, dan carpenter ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-20 14:57 ` [lustre-devel] " Hammond, John @ 2016-12-20 19:07 ` Dan Carpenter -1 siblings, 0 replies; 35+ messages in thread From: Dan Carpenter @ 2016-12-20 19:07 UTC (permalink / raw) To: Hammond, John Cc: Bruce Korb, devel, Dilger, Andreas, Kees Cook, Greg Kroah-Hartman, Linux Kernel Mailing List, Drokin, Oleg, Vitaly Fertman, Liu, Emoly, Faccini, Bruno, Lustre Development List On Tue, Dec 20, 2016 at 02:57:17PM +0000, Hammond, John wrote: > "{ NULL }" is valid ISO C, but unfortunately "{}" is not. In the kernel we don't care. We use lots of GCC extensions. regards, dan carpenter ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-20 19:07 ` Dan Carpenter 0 siblings, 0 replies; 35+ messages in thread From: Dan Carpenter @ 2016-12-20 19:07 UTC (permalink / raw) To: Hammond, John Cc: Bruce Korb, devel, Dilger, Andreas, Kees Cook, Greg Kroah-Hartman, Linux Kernel Mailing List, Drokin, Oleg, Vitaly Fertman, Liu, Emoly, Faccini, Bruno, Lustre Development List On Tue, Dec 20, 2016 at 02:57:17PM +0000, Hammond, John wrote: > "{ NULL }" is valid ISO C, but unfortunately "{}" is not. In the kernel we don't care. We use lots of GCC extensions. regards, dan carpenter ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-20 19:07 ` [lustre-devel] " Dan Carpenter @ 2016-12-20 19:46 ` Kees Cook -1 siblings, 0 replies; 35+ messages in thread From: Kees Cook @ 2016-12-20 19:46 UTC (permalink / raw) To: Dan Carpenter Cc: Hammond, John, Bruce Korb, devel, Dilger, Andreas, Greg Kroah-Hartman, Linux Kernel Mailing List, Drokin, Oleg, Vitaly Fertman, Liu, Emoly, Faccini, Bruno, Lustre Development List On Tue, Dec 20, 2016 at 11:07 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote: > On Tue, Dec 20, 2016 at 02:57:17PM +0000, Hammond, John wrote: >> "{ NULL }" is valid ISO C, but unfortunately "{}" is not. > > In the kernel we don't care. We use lots of GCC extensions. We depend on the compiler to do "incomplete zero-initialization" of structures that are not mentioned in an initializer. The reason { NULL } works is because the first field in the structure can take a NULL value, and then the rest are zero-initialized by the compiler. { } is the same thing, but doesn't use ordered initialization. If this style is truly unacceptable to you, then { .somefield = NULL } can work, or as you point out, if it's being initialized later, the static initializer can be dropped entirely. -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-20 19:46 ` Kees Cook 0 siblings, 0 replies; 35+ messages in thread From: Kees Cook @ 2016-12-20 19:46 UTC (permalink / raw) To: Dan Carpenter Cc: Hammond, John, Bruce Korb, devel, Dilger, Andreas, Greg Kroah-Hartman, Linux Kernel Mailing List, Drokin, Oleg, Vitaly Fertman, Liu, Emoly, Faccini, Bruno, Lustre Development List On Tue, Dec 20, 2016 at 11:07 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote: > On Tue, Dec 20, 2016 at 02:57:17PM +0000, Hammond, John wrote: >> "{ NULL }" is valid ISO C, but unfortunately "{}" is not. > > In the kernel we don't care. We use lots of GCC extensions. We depend on the compiler to do "incomplete zero-initialization" of structures that are not mentioned in an initializer. The reason { NULL } works is because the first field in the structure can take a NULL value, and then the rest are zero-initialized by the compiler. { } is the same thing, but doesn't use ordered initialization. If this style is truly unacceptable to you, then { .somefield = NULL } can work, or as you point out, if it's being initialized later, the static initializer can be dropped entirely. -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-19 16:22 ` [lustre-devel] " James Simmons (?) (?) @ 2016-12-19 16:50 ` Patrick Farrell 2016-12-19 17:11 ` James Simmons -1 siblings, 1 reply; 35+ messages in thread From: Patrick Farrell @ 2016-12-19 16:50 UTC (permalink / raw) To: lustre-devel 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. Kees, 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 <lustre-devel-bounces@lists.lustre.org> on behalf of James Simmons <jsimmons@infradead.org> Sent: Monday, December 19, 2016 10:22:58 AM To: Kees Cook Cc: devel at driverdev.osuosl.org; Greg Kroah-Hartman; linux-kernel at vger.kernel.org; Oleg Drokin; Vitaly Fertman; Bruce Korb; Emoly Liu; lustre-devel at 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 <keescook@chromium.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. 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 at lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20161219/bd5785da/attachment.htm> ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-19 16:50 ` Patrick Farrell @ 2016-12-19 17:11 ` James Simmons 0 siblings, 0 replies; 35+ messages in thread From: James Simmons @ 2016-12-19 17:11 UTC (permalink / raw) To: Patrick Farrell Cc: Kees Cook, devel, Greg Kroah-Hartman, linux-kernel, Oleg Drokin, Vitaly Fertman, Bruce Korb, Emoly Liu, lustre-devel [-- Attachment #1: Type: text/plain, Size: 2961 bytes --] > 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 <lustre-devel-bounces@lists.lustre.org> on behalf of James Simmons > <jsimmons@infradead.org> > 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 <keescook@chromium.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. 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 > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-19 17:11 ` James Simmons 0 siblings, 0 replies; 35+ messages in thread From: James Simmons @ 2016-12-19 17:11 UTC (permalink / raw) To: Patrick Farrell Cc: Kees Cook, devel, Greg Kroah-Hartman, linux-kernel, Oleg Drokin, Vitaly Fertman, Bruce Korb, Emoly Liu, lustre-devel > 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 <lustre-devel-bounces@lists.lustre.org> on behalf of James Simmons > <jsimmons@infradead.org> > Sent: Monday, December 19, 2016 10:22:58 AM > To: Kees Cook > Cc: devel at driverdev.osuosl.org; Greg Kroah-Hartman; linux-kernel at vger.kernel.org; Oleg Drokin; Vitaly > Fertman; Bruce Korb; Emoly Liu; lustre-devel at 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 <keescook@chromium.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. 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 at lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH] staging: lustre: ldlm: use designated initializers 2016-12-19 16:22 ` [lustre-devel] " James Simmons @ 2016-12-20 10:40 ` Dan Carpenter -1 siblings, 0 replies; 35+ messages in thread From: Dan Carpenter @ 2016-12-20 10:40 UTC (permalink / raw) To: James Simmons Cc: Kees Cook, devel, Andreas Dilger, Greg Kroah-Hartman, linux-kernel, Bruno Faccini, Oleg Drokin, Vitaly Fertman, John L. Hammond, Bruce Korb, Emoly Liu, lustre-devel 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@chromium.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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] [PATCH] staging: lustre: ldlm: use designated initializers @ 2016-12-20 10:40 ` Dan Carpenter 0 siblings, 0 replies; 35+ messages in thread From: Dan Carpenter @ 2016-12-20 10:40 UTC (permalink / raw) To: James Simmons Cc: Kees Cook, devel, Andreas Dilger, Greg Kroah-Hartman, linux-kernel, Bruno Faccini, Oleg Drokin, Vitaly Fertman, John L. Hammond, Bruce Korb, Emoly Liu, lustre-devel 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@chromium.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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Designated initializers, struct randomization and addressing? 2016-12-17 1:00 ` [lustre-devel] " Kees Cook @ 2016-12-20 17:29 ` Joe Perches -1 siblings, 0 replies; 35+ messages in thread From: Joe Perches @ 2016-12-20 17:29 UTC (permalink / raw) To: Kees Cook, linux-kernel, Julia Lawall, Dan Carpenter Cc: Oleg Drokin, Andreas Dilger, James Simmons, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Bruce Korb, lustre-devel, devel On Fri, 2016-12-16 at 17:00 -0800, Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. About the designated initializer patches, which by themselves are fine of course, and the fundamental randomization plugin, c guarantees that struct member ordering is as specified. how is the code to be verified so that any use of things like offsetof and any address/indexing is not impacted? ^ permalink raw reply [flat|nested] 35+ messages in thread
* [lustre-devel] Designated initializers, struct randomization and addressing? @ 2016-12-20 17:29 ` Joe Perches 0 siblings, 0 replies; 35+ messages in thread From: Joe Perches @ 2016-12-20 17:29 UTC (permalink / raw) To: Kees Cook, linux-kernel, Julia Lawall, Dan Carpenter Cc: Oleg Drokin, Andreas Dilger, James Simmons, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Bruce Korb, lustre-devel, devel On Fri, 2016-12-16 at 17:00 -0800, Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. About the designated initializer patches, which by themselves are fine of course, and the fundamental randomization plugin, c guarantees that struct member ordering is as specified. how is the code to be verified so that any use of things like offsetof and any address/indexing is not impacted? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Designated initializers, struct randomization and addressing? 2016-12-20 17:29 ` [lustre-devel] " Joe Perches (?) @ 2017-01-03 23:47 ` Kees Cook 2017-01-03 23:55 ` Bruce Korb 2017-01-04 6:27 ` Julia Lawall -1 siblings, 2 replies; 35+ messages in thread From: Kees Cook @ 2017-01-03 23:47 UTC (permalink / raw) To: Joe Perches Cc: LKML, Julia Lawall, Dan Carpenter, Oleg Drokin, Andreas Dilger, James Simmons, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Bruce Korb, devel On Tue, Dec 20, 2016 at 9:29 AM, Joe Perches <joe@perches.com> wrote: > On Fri, 2016-12-16 at 17:00 -0800, Kees Cook wrote: >> Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. > > About the designated initializer patches, > which by themselves are fine of course, > and the fundamental randomization plugin, > c guarantees that struct member ordering > is as specified. > > how is the code to be verified so that > any use of things like offsetof and any > address/indexing is not impacted? AIUI, offsetof() works correctly in the face of this plugin, since the ordering happens before the pass that handles offsetof(). Anything that _does not_ use offsetof(), however, needs fixing. Based on the work done in grsecurity, I don't see any added offsetof() uses that are specific to the randomization plugin. (Note that the randomization plugin is only on function pointer structures, where using an offsetof() should be rare to none, and on hand-selected structures, where missing offsetof() should be easy to audit.) -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Designated initializers, struct randomization and addressing? 2017-01-03 23:47 ` Kees Cook @ 2017-01-03 23:55 ` Bruce Korb 2017-01-04 0:13 ` Kees Cook 2017-01-04 6:27 ` Julia Lawall 1 sibling, 1 reply; 35+ messages in thread From: Bruce Korb @ 2017-01-03 23:55 UTC (permalink / raw) To: Kees Cook Cc: Joe Perches, LKML, Julia Lawall, Dan Carpenter, Oleg Drokin, Andreas Dilger, James Simmons, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, devel As a tangential party, I am a bit curious: does the randomization plugin result in a compact structure? I ask because I know many/most programmers don't bother with it and so doing so ought to make the data more compact. On Tue, Jan 3, 2017 at 3:47 PM, Kees Cook <keescook@chromium.org> wrote: >> how is the code to be verified so that >> any use of things like offsetof and any >> address/indexing is not impacted? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Designated initializers, struct randomization and addressing? 2017-01-03 23:55 ` Bruce Korb @ 2017-01-04 0:13 ` Kees Cook 0 siblings, 0 replies; 35+ messages in thread From: Kees Cook @ 2017-01-04 0:13 UTC (permalink / raw) To: Bruce Korb Cc: Joe Perches, LKML, Julia Lawall, Dan Carpenter, Oleg Drokin, Andreas Dilger, James Simmons, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, devel On Tue, Jan 3, 2017 at 3:55 PM, Bruce Korb <bruce.korb@gmail.com> wrote: > On Tue, Jan 3, 2017 at 3:47 PM, Kees Cook <keescook@chromium.org> wrote: >>> how is the code to be verified so that >>> any use of things like offsetof and any >>> address/indexing is not impacted? > > As a tangential party, I am a bit curious: does the randomization > plugin result in a compact structure? I ask because I know many/most > programmers don't bother with it and so doing so ought to make the > data more compact. http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/tree/scripts/gcc-plugins/randomize_layout_plugin.c?h=kspp/gcc-plugin/randstruct See full_shuffle() and performance_shuffle(). The latter keeps variables in the same cacheline. Neither attempt any kind of compaction. -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Designated initializers, struct randomization and addressing? 2017-01-03 23:47 ` Kees Cook 2017-01-03 23:55 ` Bruce Korb @ 2017-01-04 6:27 ` Julia Lawall 2017-01-04 6:35 ` Kees Cook 1 sibling, 1 reply; 35+ messages in thread From: Julia Lawall @ 2017-01-04 6:27 UTC (permalink / raw) To: Kees Cook Cc: Joe Perches, LKML, Dan Carpenter, Oleg Drokin, Andreas Dilger, James Simmons, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Bruce Korb, devel On Tue, 3 Jan 2017, Kees Cook wrote: > On Tue, Dec 20, 2016 at 9:29 AM, Joe Perches <joe@perches.com> wrote: > > On Fri, 2016-12-16 at 17:00 -0800, Kees Cook wrote: > >> Prepare to mark sensitive kernel structures for randomization by making > > sure they're using designated initializers. > > > > About the designated initializer patches, > > which by themselves are fine of course, > > and the fundamental randomization plugin, > > c guarantees that struct member ordering > > is as specified. > > > > how is the code to be verified so that > > any use of things like offsetof and any > > address/indexing is not impacted? > > AIUI, offsetof() works correctly in the face of this plugin, since the > ordering happens before the pass that handles offsetof(). Anything > that _does not_ use offsetof(), however, needs fixing. Based on the > work done in grsecurity, I don't see any added offsetof() uses that > are specific to the randomization plugin. > > (Note that the randomization plugin is only on function pointer > structures, where using an offsetof() should be rare to none, and on > hand-selected structures, where missing offsetof() should be easy to > audit.) What is the precise definition of "function pointer structures"? Only function pointers? At least one function pointer? thanks, julia ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Designated initializers, struct randomization and addressing? 2017-01-04 6:27 ` Julia Lawall @ 2017-01-04 6:35 ` Kees Cook 2017-01-04 16:55 ` Stephen Hemminger 0 siblings, 1 reply; 35+ messages in thread From: Kees Cook @ 2017-01-04 6:35 UTC (permalink / raw) To: Julia Lawall Cc: Joe Perches, LKML, Dan Carpenter, Oleg Drokin, Andreas Dilger, James Simmons, Greg Kroah-Hartman, John L. Hammond, Emoly Liu, Vitaly Fertman, Bruno Faccini, Bruce Korb, devel On Tue, Jan 3, 2017 at 10:27 PM, Julia Lawall <julia.lawall@lip6.fr> wrote: > > > On Tue, 3 Jan 2017, Kees Cook wrote: > >> On Tue, Dec 20, 2016 at 9:29 AM, Joe Perches <joe@perches.com> wrote: >> > On Fri, 2016-12-16 at 17:00 -0800, Kees Cook wrote: >> >> Prepare to mark sensitive kernel structures for randomization by making >> > sure they're using designated initializers. >> > >> > About the designated initializer patches, >> > which by themselves are fine of course, >> > and the fundamental randomization plugin, >> > c guarantees that struct member ordering >> > is as specified. >> > >> > how is the code to be verified so that >> > any use of things like offsetof and any >> > address/indexing is not impacted? >> >> AIUI, offsetof() works correctly in the face of this plugin, since the >> ordering happens before the pass that handles offsetof(). Anything >> that _does not_ use offsetof(), however, needs fixing. Based on the >> work done in grsecurity, I don't see any added offsetof() uses that >> are specific to the randomization plugin. >> >> (Note that the randomization plugin is only on function pointer >> structures, where using an offsetof() should be rare to none, and on >> hand-selected structures, where missing offsetof() should be easy to >> audit.) > > What is the precise definition of "function pointer structures"? Only > function pointers? At least one function pointer? For randstruct and constify, the automatic selection is done on structures with only function pointers. (Additional structures can be added via a compiler attribute marking.) See is_pure_ops_struct(): http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/tree/scripts/gcc-plugins/randomize_layout_plugin.c?h=kspp/gcc-plugin/randstruct -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Designated initializers, struct randomization and addressing? 2017-01-04 6:35 ` Kees Cook @ 2017-01-04 16:55 ` Stephen Hemminger 2017-01-04 17:37 ` Julia Lawall 2017-01-04 22:30 ` Kees Cook 0 siblings, 2 replies; 35+ messages in thread From: Stephen Hemminger @ 2017-01-04 16:55 UTC (permalink / raw) To: Kees Cook Cc: Julia Lawall, devel, Greg Kroah-Hartman, LKML, Bruno Faccini, Oleg Drokin, Vitaly Fertman, Joe Perches, Andreas Dilger, John L. Hammond, Bruce Korb, Emoly Liu On Tue, 3 Jan 2017 22:35:26 -0800 Kees Cook <keescook@chromium.org> wrote: > For randstruct and constify, the automatic selection is done on > structures with only function pointers. (Additional structures can be > added via a compiler attribute marking.) > > See is_pure_ops_struct(): Is there anyway to use this plugin to identify pure_ops structures not already marked as const? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Designated initializers, struct randomization and addressing? 2017-01-04 16:55 ` Stephen Hemminger @ 2017-01-04 17:37 ` Julia Lawall 2017-01-04 22:30 ` Kees Cook 1 sibling, 0 replies; 35+ messages in thread From: Julia Lawall @ 2017-01-04 17:37 UTC (permalink / raw) To: Stephen Hemminger Cc: Kees Cook, devel, Greg Kroah-Hartman, LKML, Bruno Faccini, Oleg Drokin, Vitaly Fertman, Joe Perches, Andreas Dilger, John L. Hammond, Bruce Korb, Emoly Liu On Wed, 4 Jan 2017, Stephen Hemminger wrote: > On Tue, 3 Jan 2017 22:35:26 -0800 > Kees Cook <keescook@chromium.org> wrote: > > > For randstruct and constify, the automatic selection is done on > > structures with only function pointers. (Additional structures can be > > added via a compiler attribute marking.) > > > > See is_pure_ops_struct(): > > Is there anyway to use this plugin to identify pure_ops structures not already marked as const? Here is a list collected with Coccinelle. The file names and the line numbers are the instances of non-const structures. julia vpbe_device_ops: drivers/media/platform/davinci/vpbe.c:797 mbus_hw_ops: drivers/misc/mic/host/mic_boot.c:374 drivers/misc/mic/card/mic_x100.c:237 fcoe_sysfs_function_template: drivers/scsi/fcoe/fcoe.c:160 drivers/scsi/bnx2fc/bnx2fc_fcoe.c:2812 nfc_phy_ops: drivers/nfc/st-nci/spi.c:220 drivers/nfc/st-nci/i2c.c:205 drm_bridge_funcs: drivers/gpu/drm/bridge/adv7511/adv7511_drv.c:831 prm_ll_data: arch/arm/mach-omap2/prm2xxx.c:214 arch/arm/mach-omap2/prm33xx.c:374 ptlrpc_sec_cops: drivers/staging/lustre/lustre/ptlrpc/sec_plain.c:969 drivers/staging/lustre/lustre/ptlrpc/sec_null.c:379 cfg80211_ops: drivers/net/wireless/intel/ipw2x00/libipw_module.c:66 fc_rport_operations: drivers/scsi/fcoe/fcoe_ctlr.c:2165 thermal_zone_of_device_ops: drivers/hwmon/scpi-hwmon.c:93 ui_helpline: tools/perf/ui/tui/helpline.c:51 skl_dsp_fw_ops: sound/soc/intel/skylake/bxt-sst.c:552 iomap_ops: fs/ext4/inode.c:3423 fs/xfs/xfs_iomap.c:1193 fs/xfs/xfs_iomap.c:1147 fs/ext2/inode.c:845 fpga_bridge_ops: drivers/fpga/altera-freeze-bridge.c:206 qlcnic_nic_template: drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c:82 emitter: scripts/dtc/flattree.c:107 scripts/dtc/flattree.c:233 hist_entry_ops: tools/perf/builtin-c2c.c:149 pccard_resource_ops: drivers/pcmcia/rsrc_mgr.c:61 mcfqspi_cs_control: arch/m68k/coldfire/device.c:308 z8530_irqhandler: drivers/net/wan/z85230.c:613 drivers/net/wan/z85230.c:486 drivers/net/wan/z85230.c:681 drivers/net/wan/z85230.c:607 snd_soc_dai_ops: sound/soc/pxa/mmp-sspa.c:384 sound/soc/codecs/max9867.c:354 sound/soc/codecs/msm8916-wcd-digital.c:791 sound/soc/codecs/rt5663.c:2861 drivers/staging/greybus/audio_codec.c:672 amba_pl010_data: arch/arm/mach-ep93xx/core.c:172 snd_pcm_ops: sound/sh/aica.c:439 sound/ppc/snd_ps3.c:775 sound/pci/au88x0/au88x0_pcm.c:442 sound/pci/sis7019.c:875 sound/pci/sis7019.c:886 sound/soc/au1x/dbdma2.c:307 sound/soc/blackfin/bf5xx-ac97-pcm.c:301 sound/soc/fsl/mpc5200_dma.c:290 sound/soc/pxa/pxa2xx-pcm.c:48 sound/arm/aaci.c:638 sound/arm/aaci.c:741 sound/arm/pxa2xx-pcm.c:71 sound/usb/caiaq/audio.c:341 sound/usb/line6/playback.c:396 sound/usb/hiface/pcm.c:516 sound/atmel/ac97c.c:628 sound/atmel/ac97c.c:639 sound/isa/sb/sb8_main.c:575 sound/isa/sb/sb8_main.c:586 sound/sparc/cs4231.c:1206 sound/sparc/cs4231.c:1217 sound/drivers/vx/vx_pcm.c:876 sound/drivers/vx/vx_pcm.c:1096 nfc_llc_ops: net/nfc/hci/llc_nop.c:85 xpc_interface: drivers/misc/sgi-xp/xp_main.c:80 intel_gvt_mpt: drivers/gpu/drm/i915/gvt/kvmgt.c:1455 i40iw_device_uk_ops: drivers/infiniband/hw/i40iw/i40iw_uk.c:936 radeon_audio_basic_funcs: drivers/gpu/drm/radeon/radeon_audio.c:128 drivers/gpu/drm/radeon/radeon_audio.c:146 drivers/gpu/drm/radeon/radeon_audio.c:140 drivers/gpu/drm/radeon/radeon_audio.c:134 vop_hw_ops: drivers/misc/mic/card/mic_device.c:312 imx_pwm_data: drivers/pwm/pwm-imx.c:261 drivers/pwm/pwm-imx.c:256 pv_time_ops: arch/x86/kernel/paravirt.c:310 smp_ops_t: arch/powerpc/platforms/pasemi/setup.c:108 arch/powerpc/platforms/chrp/smp.c:46 drm_framebuffer_funcs: drivers/gpu/drm/drm_fb_cma_helper.c:123 snd_compr_ops: sound/soc/soc-compress.c:683 sound/soc/soc-compress.c:698 sound/soc/codecs/wm5110.c:2367 drm_plane_funcs: drivers/gpu/drm/exynos/exynos_drm_plane.c:172 qed_selftest_ops: drivers/net/ethernet/qlogic/qed/qed_main.c:1568 mipi_dsi_host_ops: drivers/gpu/drm/msm/dsi/dsi_host.c:1527 i40iw_pd_ops: drivers/infiniband/hw/i40iw/i40iw_ctrl.c:4892 m48t86_ops: arch/arm/mach-orion5x/ts78xx-setup.c:98 sdhci_ops: drivers/mmc/host/sdhci-s3c.c:384 cpu_pm_ops: arch/arm/mach-omap2/omap-mpuss-lowpower.c:110 abx500_ops: drivers/mfd/ab3100-core.c:392 nfnl_ct_hook: net/netfilter/nf_conntrack_netlink.c:2392 md_cluster_operations: drivers/md/md-cluster.c:1265 intel_gvt_irq_ops: drivers/gpu/drm/i915/gvt/interrupt.c:629 isp_operations: drivers/scsi/qla2xxx/qla_os.c:2262 drivers/scsi/qla2xxx/qla_os.c:2223 drivers/scsi/qla2xxx/qla_os.c:2145 drivers/scsi/qla2xxx/qla_os.c:2106 drivers/scsi/qla2xxx/qla_os.c:2184 drivers/scsi/qla2xxx/qla_os.c:2301 drivers/scsi/qla2xxx/qla_os.c:2067 drivers/scsi/qla2xxx/qla_os.c:2028 drivers/scsi/qla2xxx/qla_os.c:1989 drivers/scsi/qla2xxx/qla_os.c:1950 mmp_overlay_ops: drivers/video/fbdev/mmp/hw/mmp_ctrl.c:320 iommu_table_group_ops: arch/powerpc/platforms/powernv/pci-ioda.c:2439 arch/powerpc/platforms/powernv/pci-ioda.c:2523 aes_ops: arch/sparc/crypto/aes_glue.c:151 arch/sparc/crypto/aes_glue.c:139 arch/sparc/crypto/aes_glue.c:127 sparc32_cachetlb_ops: arch/sparc/mm/srmmu.c:1478 arch/sparc/mm/srmmu.c:1447 arch/sparc/mm/srmmu.c:1762 mcp_ops: drivers/mfd/mcp-sa11x0.c:147 reset_control_ops: drivers/soc/dove/pmu.c:90 ib_dma_mapping_ops: drivers/infiniband/hw/hfi1/dma.c:171 drivers/infiniband/sw/rxe/rxe_dma.c:169 otg_fsm_ops: drivers/usb/chipidea/otg_fsm.c:574 ftrace_probe_ops: kernel/trace/trace_functions.c:512 kernel/trace/trace_functions.c:487 kernel/trace/trace_functions.c:517 kernel/trace/trace_functions.c:492 kernel/trace/trace_functions.c:522 kernel/trace/trace_functions.c:497 kernel/trace/trace_functions.c:502 kernel/trace/trace_functions.c:507 wl1271_if_operations: drivers/net/wireless/ti/wlcore/spi.c:422 drivers/net/wireless/ti/wlcore/sdio.c:211 vm_operations_struct: drivers/usb/core/devio.c:219 mvumi_instance_template: drivers/scsi/mvumi.c:2029 drivers/scsi/mvumi.c:2018 lpc32xx_mlc_platform_data: arch/arm/mach-lpc32xx/phy3250.c:157 stacktrace_ops: arch/sh/oprofile/backtrace.c:40 pci_error_handlers: drivers/scsi/bfa/bfad.c:1686 of_pdt_ops: arch/sparc/kernel/prom_common.c:147 v4l2_subdev_video_ops: drivers/media/i2c/soc_camera/tw9910.c:904 drivers/media/i2c/soc_camera/mt9v022.c:861 drivers/media/i2c/mt9t001.c:829 drivers/media/platform/soc_camera/soc_camera_platform.c:113 hnae_buf_ops: drivers/net/ethernet/hisilicon/hns/hnae.c:88 fd_dma_ops: arch/powerpc/include/asm/floppy.h:173 arch/powerpc/include/asm/floppy.h:165 mmu_rb_ops: drivers/infiniband/hw/hfi1/user_sdma.c:320 libfc_function_template: drivers/scsi/fcoe/fcoe.c:174 drivers/scsi/bnx2fc/bnx2fc_fcoe.c:2966 s5p_mfc_hw_ops: drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c:1597 lpc32xx_slc_platform_data: arch/arm/mach-lpc32xx/phy3250.c:153 mem_access: arch/sh/kernel/traps_32.c:74 rtl_hal_ops: drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c:257 ttm_backend_func: drivers/gpu/drm/ast/ast_ttm.c:196 drivers/gpu/drm/qxl/qxl_ttm.c:292 drivers/gpu/drm/ttm/ttm_agp_backend.c:106 i40iw_cqp_misc_ops: drivers/infiniband/hw/i40iw/i40iw_ctrl.c:4927 raw3270_fn: drivers/s390/char/fs3270.c:417 drivers/s390/char/con3270.c:429 bcache_ops: arch/mips/mm/sc-ip22.c:177 usb_gadget_ops: drivers/usb/gadget/udc/fotg210-udc.c:1061 scif_hw_ops: drivers/misc/mic/card/mic_device.c:241 rfkill_ops: drivers/platform/x86/dell-rbtn.c:113 qlcnic_hardware_ops: drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c:47 header_ops: net/bluetooth/6lowpan.c:642 cpuidle_exynos_data: arch/arm/mach-exynos/pm.c:343 microcode_ops: arch/x86/kernel/cpu/microcode/intel.c:978 megasas_instance_template: drivers/scsi/megaraid/megaraid_sas_fusion.c:3679 perf_guest_info_callbacks: arch/x86/xen/pmu.c:450 dma_fence_ops: drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:228 pci_bios_ops: drivers/parisc/dino.c:645 drm_encoder_funcs: drivers/gpu/drm/rockchip/inno_hdmi.c:541 clkops: arch/arm/mach-mmp/clock-mmp2.c:66 matrox_switch: drivers/video/fbdev/matrox/matroxfb_DAC1064.c:1090 drivers/video/fbdev/matrox/matroxfb_DAC1064.c:1097 ptlrpc_sec_sops: drivers/staging/lustre/lustre/ptlrpc/sec_plain.c:983 drivers/staging/lustre/lustre/ptlrpc/sec_null.c:391 omap_mcbsp_ops: arch/arm/mach-omap1/mcbsp.c:80 i40iw_mr_ops: drivers/infiniband/hw/i40iw/i40iw_ctrl.c:4918 pcie_soc_ops: drivers/pci/host/pcie-hisi.c:301 drivers/pci/host/pcie-hisi.c:297 actions: tools/testing/selftests/powerpc/benchmarks/context_switch.c:234 tools/testing/selftests/powerpc/benchmarks/context_switch.c:195 tools/testing/selftests/powerpc/benchmarks/context_switch.c:349 od_ops: drivers/cpufreq/cpufreq_ondemand.c:410 sas_domain_function_template: drivers/scsi/pm8001/pm8001_init.c:99 concap_proto_ops: drivers/isdn/i4l/isdn_x25iface.c:55 cfs_hash_ops: drivers/staging/lustre/lustre/lov/lov_pool.c:141 drivers/staging/lustre/lustre/obdclass/obd_config.c:1510 drivers/staging/lustre/lustre/ldlm/ldlm_resource.c:539 drivers/staging/lustre/lustre/ldlm/ldlm_resource.c:550 clk_ops: drivers/gpu/drm/imx/imx-tve.c:449 drivers/clk/spear/clk-aux-synth.c:131 drivers/clk/spear/clk-frac-synth.c:119 drivers/clk/mmp/clk-apbc.c:117 v4l2_subdev_core_ops: drivers/media/i2c/soc_camera/tw9910.c:840 drivers/media/i2c/soc_camera/mt9v022.c:773 drivers/media/i2c/mt9t001.c:825 drivers/media/platform/soc_camera/soc_camera_platform.c:62 mal_commac_ops: drivers/net/ethernet/ibm/emac/core.c:1986 drivers/net/ethernet/ibm/emac/core.c:1979 qed_ll2_cb_ops: drivers/scsi/qedi/qedi_main.c:1577 llog_operations: drivers/staging/lustre/lustre/ptlrpc/llog_client.c:332 xpc_arch_operations: drivers/misc/sgi-xp/xpc_sn2.c:2354 ieee80211_ops: drivers/net/wireless/ath/ath9k/main.c:2659 drivers/net/wireless/rsi/rsi_91x_mac80211.c:1180 perf_error_ops: tools/perf/ui/tui/util.c:253 usb_phy_io_ops: drivers/usb/phy/phy-ulpi-viewport.c:78 lane2_ops: net/atm/lec.c:113 videobuf_queue_ops: drivers/media/usb/cx231xx/cx231xx-vbi.c:288 dac_ops: drivers/video/fbdev/arkfb.c:432 drm_connector_helper_funcs: drivers/gpu/drm/zte/zx_hdmi.c:293 md_ops: drivers/staging/lustre/lustre/mdc/mdc_request.c:2709 ethtool_ops: drivers/net/ethernet/broadcom/bcm63xx_enet.c:2673 exynos_drm_ipp_ops: drivers/gpu/drm/exynos/exynos_drm_rotator.c:458 drivers/gpu/drm/exynos/exynos_drm_rotator.c:464 vexpress_config_bridge_ops: drivers/misc/vexpress-syscfg.c:243 plat_sci_port_ops: arch/sh/kernel/cpu/sh3/serial-sh770x.c:31 arch/sh/kernel/cpu/sh3/serial-sh7710.c:18 trace_sched_handler: tools/perf/builtin-sched.c:3267 tools/perf/builtin-sched.c:3264 tools/perf/builtin-sched.c:3258 x86_cpuinit_ops: arch/x86/kernel/x86_init.c:86 uart_ops: drivers/tty/serial/omap-serial.c:1398 drivers/tty/serial/sunhv.c:373 drivers/tty/serial/ioc4_serial.c:2599 drivers/tty/serial/pxa.c:765 drivers/tty/serial/ip22zilog.c:933 drivers/tty/serial/sunzilog.c:1049 wkup_m3_ipc_ops: drivers/soc/ti/wkup_m3_ipc.c:332 ui_progress_ops: tools/perf/ui/progress.c:8 k_clock: kernel/time/posix-clock.c:437 spu_context_ops: arch/powerpc/platforms/cell/spufs/hw_ops.c:322 mca_msr_regs: arch/x86/kernel/cpu/mcheck/mce.c:276 i40iw_qp_uk_ops: drivers/infiniband/hw/i40iw/i40iw_uk.c:915 cm_ll_data: arch/arm/mach-omap2/cm2xxx.c:391 cl_lock_operations: drivers/staging/lustre/lustre/obdecho/echo_client.c:322 net_device_ops: drivers/net/ethernet/xilinx/xilinx_emaclite.c:1222 event_trigger_ops: kernel/trace/trace_events_hist.c:1654 kernel/trace/trace_events_hist.c:1661 kernel/trace/trace_events_hist.c:1668 kernel/trace/trace_events_hist.c:1675 kernel/trace/trace_events_hist.c:1261 kernel/trace/trace_events_hist.c:1295 iommu_gather_ops: drivers/iommu/io-pgtable-arm-v7s.c:744 smb_version_operations: fs/cifs/smb1ops.c:1018 fs/cifs/smb2ops.c:1797 fs/cifs/smb2ops.c:1709 fs/cifs/smb2ops.c:1628 fs/cifs/smb2ops.c:1548 v4l2_ioctl_ops: drivers/media/usb/usbtv/usbtv-video.c:610 snd_soc_ops: sound/soc/mediatek/mt8173/mt8173-rt5650-rt5676.c:82 sound/soc/fsl/phycore-ac97.c:26 sound/soc/samsung/smartq_wm8987.c:80 sound/soc/samsung/arndale_rt5631.c:56 sound/soc/omap/omap-abe-twl6040.c:73 sound/soc/omap/omap-abe-twl6040.c:99 sound/soc/omap/n810.c:127 sound/soc/omap/omap3pandora.c:187 drm_simple_display_pipe_funcs: drivers/gpu/drm/mxsfb/mxsfb_drv.c:129 sst_ops: sound/soc/intel/skylake/bxt-sst.c:562 fb_tile_ops: drivers/video/fbdev/arkfb.c:154 conf_printer: scripts/kconfig/confdata.c:623 scripts/kconfig/confdata.c:530 scripts/kconfig/confdata.c:604 olpc_ec_driver: arch/x86/platform/olpc/olpc.c:363 arch/x86/platform/olpc/olpc.c:370 ath_ps_ops: drivers/net/wireless/ath/ath9k/init.c:107 irq_domain_ops: kernel/irq/generic-chip.c:437 arch/mips/ath25/ar5312.c:124 drivers/edac/altera_edac.c:1828 drivers/iommu/amd_iommu.c:4256 drivers/iommu/intel_irq_remapping.c:1402 drivers/mfd/fsl-imx25-tsadc.c:62 drivers/irqchip/irq-imx-gpcv2.c:203 drivers/irqchip/irq-mbigen.c:233 drivers/irqchip/irq-stm32-exti.c:125 alpha_agp_ops: arch/alpha/kernel/core_titan.c:716 ptlrpc_ctx_ops: drivers/staging/lustre/lustre/ptlrpc/sec_plain.c:960 drivers/staging/lustre/lustre/ptlrpc/sec_null.c:373 rxe_ifc_ops: drivers/infiniband/sw/rxe/rxe_net.c:525 dev_power_governor: drivers/base/power/domain_governor.c:229 drivers/base/power/domain_governor.c:237 nfcmrvl_if_ops: drivers/nfc/nfcmrvl/uart.c:63 nfc_digital_ops: drivers/nfc/port100.c:1466 drivers/nfc/trf7970a.c:1858 snd_vx_ops: sound/pcmcia/vx/vxp_ops.c:597 sound/pci/vx222/vx222_ops.c:1000 sound/pci/vx222/vx222_ops.c:1020 kernfs_syscall_ops: kernel/cgroup/cgroup.c:4415 hid_ll_driver: drivers/hid/i2c-hid/i2c-hid.c:851 lcd_ops: drivers/hid/hid-picolcd_lcd.c:59 super_operations: drivers/staging/lustre/lustre/llite/super25.c:73 platform_suspend_ops: arch/arm/mach-mxs/pm.c:33 nf_exp_event_notifier: net/netfilter/nf_conntrack_netlink.c:3263 kvm_mips_callbacks: arch/mips/kvm/trap_emul.c:648 snd_rawmidi_ops: sound/usb/6fire/midi.c:142 sound/usb/6fire/midi.c:149 sound/drivers/mts64.c:752 sound/drivers/mts64.c:758 sound/firewire/bebob/bebob_midi.c:115 sound/firewire/bebob/bebob_midi.c:109 drivers/hid/hid-prodikeys.c:596 dev_pm_ops: drivers/i2c/busses/i2c-omap.c:1507 omap_dss_driver: drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c:357 drivers/gpu/drm/omapdrm/displays/panel-dpi.c:153 radeon_audio_funcs: drivers/gpu/drm/radeon/radeon_audio.c:152 drivers/gpu/drm/radeon/radeon_audio.c:215 drivers/gpu/drm/radeon/radeon_audio.c:232 drivers/gpu/drm/radeon/radeon_audio.c:187 drivers/gpu/drm/radeon/radeon_audio.c:203 drivers/gpu/drm/radeon/radeon_audio.c:164 drivers/gpu/drm/radeon/radeon_audio.c:178 hwicap_driver_config: drivers/char/xilinx_hwicap/xilinx_hwicap.c:714 drivers/char/xilinx_hwicap/xilinx_hwicap.c:707 mxc_extra_irq: arch/arm/mach-imx/avic.c:79 kvm_io_device_ops: virt/kvm/arm/vgic/vgic-mmio.c:550 sh_mobile_lcdc_sys_bus_ops: drivers/video/fbdev/sh_mobile_lcdcfb.c:441 drm_mode_config_funcs: drivers/gpu/drm/arc/arcpgu_drv.c:34 ufs_qcom_phy_specific_ops: drivers/phy/phy-qcom-ufs-qmp-20nm.c:166 pci_controller_ops: arch/powerpc/platforms/powermac/pci.c:1257 pwrdm_ops: arch/arm/mach-omap2/prm2xxx.c:198 arch/arm/mach-omap2/prm33xx.c:356 ace_reg_ops: drivers/block/xsysace.c:337 drivers/block/xsysace.c:330 drivers/block/xsysace.c:265 e1000_nvm_operations: drivers/net/ethernet/intel/igb/e1000_82575.c:2931 amd_irte_ops: drivers/iommu/amd_iommu.c:4101 drivers/iommu/amd_iommu.c:4111 sa1100_port_fns: arch/arm/mach-sa1100/badge4.c:317 hwbus_ops: drivers/net/wireless/st/cw1200/cw1200_sdio.c:268 drivers/net/wireless/st/cw1200/cw1200_spi.c:355 i40iw_aeq_ops: drivers/infiniband/hw/i40iw/i40iw_ctrl.c:4881 e1000_mac_operations: drivers/net/ethernet/intel/igb/e1000_82575.c:2911 nfc_ops: net/nfc/digital_core.c:742 net/nfc/nci/core.c:1104 snd_ac97_bus_ops: sound/pci/sis7019.c:1020 sound/soc/cirrus/ep93xx-ac97.c:245 sound/soc/pxa/pxa2xx-ac97.c:46 sound/arm/aaci.c:830 sound/atmel/ac97c.c:948 hnae_ae_ops: drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:830 v4l2_m2m_ops: drivers/media/platform/exynos-gsc/gsc-m2m.c:750 drivers/media/platform/vim2m.c:984 drivers/media/platform/m2m-deinterlace.c:991 menelaus_platform_data: arch/arm/mach-omap2/board-n8x0.c:571 fsnotify_ops: fs/notify/dnotify/dnotify.c:139 io_pgtable_init_fns: drivers/iommu/io-pgtable-arm.c:883 drivers/iommu/io-pgtable-arm.c:878 drivers/iommu/io-pgtable-arm.c:893 drivers/iommu/io-pgtable-arm.c:888 pci_ops: arch/mips/pci/pci-sb1250.c:184 arch/mips/pci/pci-ar71xx.c:224 arch/mips/pci/ops-sni.c:161 arch/mips/pci/ops-sni.c:86 arch/mips/pci/pci-alchemy.c:295 arch/mips/pci/ops-msc.c:144 arch/frv/mb93090-mb00/pci-vdk.c:170 arch/powerpc/kernel/pci-common.c:1604 arch/powerpc/platforms/powermac/pci.c:427 arch/powerpc/platforms/powermac/pci.c:380 arch/powerpc/platforms/powermac/pci.c:165 arch/powerpc/platforms/powermac/pci.c:200 arch/powerpc/platforms/52xx/efika.c:64 arch/arm/mach-footbridge/dc21285.c:131 arch/sparc/kernel/pci_common.c:312 arch/sparc/kernel/pci_common.c:251 arch/x86/pci/intel_mid_pci.c:274 drivers/pci/host/pci-hyperv.c:688 configfs_item_operations: drivers/nvme/target/configfs.c:637 drivers/nvme/target/configfs.c:735 drivers/nvme/target/configfs.c:507 drivers/nvme/target/configfs.c:788 drivers/nvme/target/configfs.c:393 drivers/nvme/target/configfs.c:848 drivers/nvme/target/configfs.c:580 drivers/usb/gadget/function/f_serial.c:268 drivers/usb/gadget/function/f_uac1.c:780 drivers/usb/gadget/function/f_acm.c:771 sh_clk_ops: drivers/sh/clk/cpg.c:88 drivers/sh/clk/cpg.c:201 drivers/sh/clk/cpg.c:195 drivers/sh/clk/cpg.c:327 drivers/sh/clk/cpg.c:380 drivers/sh/clk/cpg.c:459 smp_ops: arch/x86/kernel/smp.c:341 sbc_ops: drivers/target/target_core_iblock.c:820 vdec_common_if: drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_if.c:955 hdmi_phy_ops: drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c:208 kset_uevent_ops: fs/dlm/lockspace.c:238 clkdm_ops: arch/arm/mach-omap2/cm2xxx.c:317 item_operations: fs/reiserfs/item_ops.c:106 fs/reiserfs/item_ops.c:341 fs/reiserfs/item_ops.c:726 fs/reiserfs/item_ops.c:628 fs/reiserfs/item_ops.c:197 smp_operations: arch/arm/mach-shmobile/platsmp-apmu.c:219 intel_gvt_gtt_gma_ops: drivers/gpu/drm/i915/gvt/gtt.c:420 mii_phy_ops: drivers/net/ethernet/ibm/emac/phy.c:458 drivers/net/ethernet/ibm/emac/phy.c:442 drivers/net/ethernet/ibm/emac/phy.c:279 drivers/net/ethernet/ibm/emac/phy.c:423 drivers/net/ethernet/ibm/emac/phy.c:343 drivers/net/ethernet/ibm/emac/phy.c:483 drm_fb_helper_funcs: drivers/gpu/drm/virtio/virtgpu_fb.c:369 tegra_cpu_car_ops: drivers/clk/tegra/clk-tegra114.c:1146 knav_range_ops: drivers/soc/ti/knav_qmss_acc.c:470 i40iw_cq_ops: drivers/infiniband/hw/i40iw/i40iw_uk.c:929 i40iw_cqp_ops: drivers/infiniband/hw/i40iw/i40iw_ctrl.c:4853 pccard_operations: drivers/pcmcia/at91_cf.c:205 drivers/pcmcia/soc_common.c:729 drivers/pcmcia/xxs1500_ss.c:199 intel_uncore_ops: arch/x86/events/intel/uncore_snbep.c:1078 arch/x86/events/intel/uncore_snbep.c:994 arch/x86/events/intel/uncore_snbep.c:653 arch/x86/events/intel/uncore_snbep.c:642 arch/x86/events/intel/uncore_snbep.c:884 arch/x86/events/intel/uncore_snbep.c:3590 arch/x86/events/intel/uncore_snbep.c:3495 arch/x86/events/intel/uncore_snbep.c:3442 arch/x86/events/intel/uncore_snbep.c:3380 arch/x86/events/intel/uncore_snbep.c:3621 arch/x86/events/intel/uncore_snbep.c:2094 arch/x86/events/intel/uncore_snbep.c:2000 arch/x86/events/intel/uncore_snbep.c:1715 arch/x86/events/intel/uncore_snbep.c:1607 arch/x86/events/intel/uncore_snbep.c:1343 arch/x86/events/intel/uncore_snbep.c:1339 arch/x86/events/intel/uncore_snbep.c:1695 arch/x86/events/intel/uncore_snbep.c:1579 arch/x86/events/intel/uncore_snbep.c:2403 arch/x86/events/intel/uncore_snbep.c:2610 arch/x86/events/intel/uncore_snbep.c:2658 arch/x86/events/intel/uncore_snbep.c:2752 arch/x86/events/intel/uncore_snbep.c:2563 drm_encoder_helper_funcs: drivers/gpu/drm/rockchip/inno_hdmi.c:533 nf_ct_event_notifier: net/netfilter/nf_conntrack_netlink.c:3259 kvm_pmu_ops: arch/x86/kvm/pmu_intel.c:345 w100_tg_info: arch/arm/mach-pxa/eseries.c:857 nfc_hci_ops: drivers/nfc/st21nfca/core.c:926 configfs_group_operations: drivers/nvme/target/configfs.c:675 drivers/nvme/target/configfs.c:760 drivers/nvme/target/configfs.c:829 drivers/nvme/target/configfs.c:432 drivers/nvme/target/configfs.c:871 drivers/iio/industrialio-sw-device.c:154 access_method: drivers/scsi/hpsa.h:608 drivers/scsi/hpsa.h:601 drivers/scsi/hpsa.h:594 drivers/scsi/hpsa.h:587 drivers/scsi/hpsa.h:580 drivers/block/cciss.h:420 drivers/block/cciss.h:404 drivers/block/cciss.h:412 dma_buf_ops: drivers/gpu/drm/udl/udl_dmabuf.c:189 arm_pmu_platdata: arch/arm/mach-ux500/cpu-db8500.c:138 dcon_platform_data: drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c:156 drivers/staging/olpc_dcon/olpc_dcon_xo_1.c:200 qla_tgt_func_tmpl: drivers/scsi/qla2xxx/tcm_qla2xxx.c:1557 cfs_hash_lock_ops: drivers/staging/lustre/lnet/libcfs/hash.c:191 drivers/staging/lustre/lnet/libcfs/hash.c:199 drivers/staging/lustre/lnet/libcfs/hash.c:159 drivers/staging/lustre/lnet/libcfs/hash.c:167 drivers/staging/lustre/lnet/libcfs/hash.c:175 drivers/staging/lustre/lnet/libcfs/hash.c:183 mdesc_mem_ops: arch/sparc/kernel/mdesc.c:125 arch/sparc/kernel/mdesc.c:163 pinctrl_ops: drivers/pinctrl/vt8500/pinctrl-wmt.c:412 drivers/pinctrl/pinctrl-st.c:864 i2c_algorithm: drivers/media/pci/dm1105/dm1105.c:578 drivers/media/pci/ngene/ngene-i2c.c:157 drivers/media/pci/mantis/mantis_i2c.c:215 drivers/media/common/b2c2/flexcop-i2c.c:220 drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c:521 drivers/media/usb/dvb-usb-v2/az6007.c:839 drivers/media/usb/usbvision/usbvision-i2c.c:170 drivers/media/usb/dvb-usb/pctv452e.c:903 drivers/media/usb/dvb-usb/friio.c:453 drivers/i2c/busses/i2c-xgene-slimpro.c:375 drivers/i2c/busses/i2c-designware-core.c:825 drivers/i2c/busses/i2c-davinci.c:736 drivers/i2c/busses/i2c-robotfuzz-osif.c:120 fsi_stream_handler: sound/soc/sh/fsi.c:1225 sound/soc/sh/fsi.c:1231 sound/soc/sh/fsi.c:1426 portals_handle_ops: drivers/staging/lustre/lustre/ldlm/ldlm_lock.c:383 max197_platform_data: arch/x86/platform/ts5500/ts5500.c:277 intel_sst_ops: sound/soc/intel/atom/sst/sst.c:168 pic32_sdhci_platform_data: arch/mips/pic32/pic32mzda/init.c:114 snd_info_entry_ops: sound/pci/mixart/mixart.c:1178 sound/pci/mixart/mixart.c:1174 sound/drivers/opl4/opl4_proc.c:92 rchan_callbacks: kernel/relay.c:321 drivers/net/wireless/ath/ath9k/common-spectral.c:1067 pci_port_ops: drivers/parisc/dino.c:289 mwifiex_if_ops: drivers/net/wireless/marvell/mwifiex/usb.c:1188 i40iw_ceq_ops: drivers/infiniband/hw/i40iw/i40iw_ctrl.c:4871 b53_io_ops: drivers/net/dsa/bcm_sf2.c:967 thermal_zone_device_ops: drivers/platform/x86/acerhdf.c:486 vio_driver_ops: drivers/net/ethernet/sun/ldmvsw.c:256 enclosure_component_callbacks: drivers/scsi/ses.c:365 drm_plane_helper_funcs: drivers/gpu/drm/sun4i/sun4i_layer.c:58 cpu_user_fns: arch/arm/mm/copypage-v4wb.c:92 arch/arm/mm/copypage-v4mc.c:112 arch/arm/mm/copypage-fa.c:83 arch/arm/mm/copypage-v4wt.c:85 cfs_hash_hlist_ops: drivers/staging/lustre/lnet/libcfs/hash.c:435 drivers/staging/lustre/lnet/libcfs/hash.c:442 drivers/staging/lustre/lnet/libcfs/hash.c:449 drivers/staging/lustre/lnet/libcfs/hash.c:456 ocfs2_stack_operations: fs/ocfs2/stack_user.c:1090 fs/ocfs2/stack_o2cb.c:417 vb2_ops: drivers/media/platform/pxa_camera.c:1533 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c:624 ti_clk_ll_ops: arch/arm/mach-omap2/clock.c:57 i40iw_hmc_ops: drivers/infiniband/hw/i40iw/i40iw_ctrl.c:4950 bau_operations: arch/x86/platform/uv/tlb_uv.c:38 arch/x86/platform/uv/tlb_uv.c:28 machine_ops: arch/sh/kernel/reboot.c:67 snd_midi_op: sound/drivers/opl3/opl3_seq.c:145 pv_init_ops: arch/x86/kernel/paravirt.c:306 drm_connector_funcs: drivers/gpu/drm/rockchip/inno_hdmi.c:595 plat_smp_ops: arch/mips/paravirt/paravirt-smp.c:135 arch/arc/kernel/mcip.c:111 rtl_btc_ops: drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c:32 unwind_libunwind_ops: tools/perf/util/unwind-libunwind-local.c:688 ldlm_valblock_ops: drivers/staging/lustre/lustre/mdc/mdc_request.c:2560 ttm_bo_driver: drivers/gpu/drm/ast/ast_ttm.c:228 drivers/gpu/drm/qxl/qxl_ttm.c:384 intel_gvt_gtt_pte_ops: drivers/gpu/drm/i915/gvt/gtt.c:410 exynos_drm_crtc_ops: drivers/gpu/drm/exynos/exynos5433_drm_decon.c:473 dma_ops: arch/arm/mach-rpc/dma.c:323 arch/arm/mach-rpc/dma.c:243 arch/arm/mach-rpc/dma.c:309 superhyway_ops: arch/sh/drivers/superhyway/ops-sh4-202.c:156 regulator_ops: drivers/regulator/ad5398.c:184 drivers/regulator/88pm8607.c:223 drivers/regulator/88pm8607.c:232 pcie_host_ops: drivers/pci/host/pcie-qcom.c:636 drivers/pci/host/pcie-armada8k.c:162 irda_platform_data: arch/arm/mach-sa1100/collie.c:125 ep93xx_spi_chip_ops: arch/arm/mach-ep93xx/vision_ep9307.c:283 arch/arm/mach-ep93xx/vision_ep9307.c:243 arch/arm/mach-ep93xx/vision_ep9307.c:194 au1200fb_platdata: arch/mips/alchemy/devboards/db1200.c:635 wlcore_ops: drivers/net/wireless/ti/wl12xx/main.c:1693 snd_device_ops: sound/i2c/other/ak4114.c:89 sound/pci/sis7019.c:1318 sound/core/compress_offload.c:1074 sound/sparc/cs4231.c:1792 sound/sparc/cs4231.c:1958 sound/drivers/pcsp/pcsp.c:45 drivers/hid/hid-prodikeys.c:609 svc_xprt_ops: net/sunrpc/svcsock.c:679 net/sunrpc/svcsock.c:1255 net/sunrpc/svcsock.c:1221 bfin_sport_transfer_ops: drivers/spi/spi-bfin-sport.c:201 drivers/spi/spi-bfin-sport.c:241 fmc_operations: drivers/fmc/fmc-fakedev.c:234 virtio_config_ops: drivers/misc/mic/vop/vop_main.c:425 intel_gvt_sched_policy_ops: drivers/gpu/drm/i915/gvt/sched_policy.c:237 plat_lcd_data: arch/arm/mach-s3c64xx/mach-smartq.c:232 trace_lock_handler: tools/perf/builtin-lock.c:646 snd_i2c_bit_ops: sound/pci/ice1712/ews.c:131 sound/isa/gus/interwave.c:204 sas_function_template: drivers/message/fusion/mptsas.c:2350 rpc_xprt_ops: net/sunrpc/xprtsock.c:2689 net/sunrpc/xprtsock.c:2711 net/sunrpc/xprtsock.c:2671 net/sunrpc/xprtsock.c:2741 net/sunrpc/xprtrdma/svc_rdma_backchannel.c:280 scpi_ops: drivers/firmware/arm_scpi.c:754 mic_smpt_ops: drivers/misc/mic/host/mic_x100.c:549 esp_driver_ops: drivers/scsi/mac_esp.c:468 mic_hw_intr_ops: drivers/misc/mic/host/mic_x100.c:578 ipmi_user_hndl: drivers/char/ipmi/ipmi_watchdog.c:988 mmc_host_ops: drivers/mmc/host/omap_hsmmc.c:1829 i40iw_ccq_ops: drivers/infiniband/hw/i40iw/i40iw_ctrl.c:4862 iommu_table_ops: arch/powerpc/sysdev/dart_iommu.c:335 arch/powerpc/platforms/pseries/iommu.c:568 arch/powerpc/platforms/pseries/iommu.c:654 au1k_irda_platform_data: arch/mips/alchemy/devboards/db1000.c:409 ins_ops: tools/perf/util/annotate.c:459 tools/perf/util/annotate.c:455 tools/perf/util/annotate.c:403 tools/perf/util/annotate.c:339 tools/perf/util/annotate.c:252 tools/perf/util/annotate.c:444 tools/perf/util/annotate.c:213 thermal_cooling_device_ops: drivers/platform/x86/intel_menlow.c:145 drivers/platform/x86/acerhdf.c:560 intel_mid_ops: arch/x86/platform/intel-mid/mfld.c:22 arch/x86/platform/intel-mid/mrfld.c:97 board_ops: drivers/tty/serial/jsm/jsm_neo.c:1396 at91_pinctrl_mux_ops: drivers/pinctrl/pinctrl-at91.c:636 drivers/pinctrl/pinctrl-at91.c:617 drivers/pinctrl/pinctrl-at91.c:608 arm_dma_allocator: arch/arm/mm/dma-mapping.c:690 arch/arm/mm/dma-mapping.c:746 arch/arm/mm/dma-mapping.c:725 arch/arm/mm/dma-mapping.c:709 concap_device_ops: drivers/isdn/i4l/isdn_concap.c:82 pn533_phy_ops: drivers/nfc/pn533/usb.c:437 ion_heap_ops: drivers/staging/android/ion/ion_chunk_heap.c:120 pv_cpu_ops: arch/x86/kernel/paravirt.c:327 wl1251_if_operations: drivers/net/wireless/ti/wl1251/sdio.c:216 csio_hw_chip_ops: drivers/scsi/csiostor/csio_hw_t5.c:390 rio_ops: drivers/rapidio/devices/tsi721.c:2629 lirc_rx51_platform_data: arch/arm/mach-omap2/pdata-quirks.c:487 tc6387xb_platform_data: arch/arm/mach-pxa/eseries.c:137 rtc_class_ops: drivers/rtc/rtc-imxdi.c:671 bnx2x_func_sp_drv_ops: drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:13565 i40e_ops: drivers/net/ethernet/intel/i40e/i40e_client.c:62 sn_pcibus_provider: arch/ia64/sn/pci/tioca_provider.c:660 v4l2_subdev_pad_ops: drivers/media/i2c/m5mols/m5mols_core.c:654 drivers/media/i2c/mt9t001.c:833 drivers/media/platform/exynos4-is/fimc-capture.c:1698 bfin_cpu_pm_fns: arch/blackfin/mach-bf609/pm.c:285 mbox_chan_ops: drivers/mailbox/mailbox-xgene-slimpro.c:177 msi_domain_ops: kernel/irq/msi.c:220 drivers/pci/host/pci-hyperv.c:961 i40iw_priv_cq_ops: drivers/infiniband/hw/i40iw/i40iw_ctrl.c:4911 i40iw_priv_qp_ops: drivers/infiniband/hw/i40iw/i40iw_ctrl.c:4896 rproc_fw_ops: drivers/remoteproc/st_slim_rproc.c:226 s3c_ide_platdata: arch/arm/mach-s3c64xx/mach-smdk6410.c:243 gpmc_nand_ops: drivers/memory/omap-gpmc.c:1124 drm_mode_config_helper_funcs: drivers/gpu/drm/arm/malidp_drv.c:104 samsung_gpio_pm: arch/arm/plat-samsung/pm-gpio.c:303 arch/arm/plat-samsung/pm-gpio.c:192 arch/arm/plat-samsung/pm-gpio.c:65 cosm_hw_ops: drivers/misc/mic/host/mic_boot.c:589 usb_ep_ops: drivers/usb/gadget/udc/mv_u3d_core.c:998 drivers/usb/gadget/udc/pxa27x_udc.c:1476 drivers/usb/gadget/udc/fsl_udc_core.c:1121 drivers/usb/dwc2/gadget.c:4089 pwm_omap_dmtimer_pdata: arch/arm/mach-omap2/pdata-quirks.c:462 xen_pci_frontend_ops: drivers/pci/xen-pcifront.c:374 saa7146_use_ops: drivers/media/common/saa7146/saa7146_vbi.c:492 s5p_mfc_hw_cmds: drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c:152 hdmi_codec_ops: drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c:85 dm_space_map: drivers/md/persistent-data/dm-space-map-disk.c:224 drivers/md/persistent-data/dm-space-map-metadata.c:547 drivers/md/persistent-data/dm-space-map-metadata.c:674 gpio_methods: sound/aoa/core/gpio-feature.c:406 sound/aoa/core/gpio-pmf.c:236 stmp3xxx_wdt_pdata: drivers/rtc/rtc-stmp3xxx.c:104 mpt_pci_driver: drivers/message/fusion/mptctl.c:2993 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Designated initializers, struct randomization and addressing? 2017-01-04 16:55 ` Stephen Hemminger 2017-01-04 17:37 ` Julia Lawall @ 2017-01-04 22:30 ` Kees Cook 1 sibling, 0 replies; 35+ messages in thread From: Kees Cook @ 2017-01-04 22:30 UTC (permalink / raw) To: Stephen Hemminger Cc: Julia Lawall, devel, Greg Kroah-Hartman, LKML, Bruno Faccini, Oleg Drokin, Vitaly Fertman, Joe Perches, Andreas Dilger, John L. Hammond, Bruce Korb, Emoly Liu On Wed, Jan 4, 2017 at 8:55 AM, Stephen Hemminger <stephen@networkplumber.org> wrote: > On Tue, 3 Jan 2017 22:35:26 -0800 > Kees Cook <keescook@chromium.org> wrote: > >> For randstruct and constify, the automatic selection is done on >> structures with only function pointers. (Additional structures can be >> added via a compiler attribute marking.) >> >> See is_pure_ops_struct(): > > Is there anyway to use this plugin to identify pure_ops structures not already marked as const? That's what the constify plugin does, yes. Though to deal with cases where something rarely written to, the pax_open_kernel/pax_close_kernel annotations are needed, which is why I don't have a sane port of the constify plugin yet. We need to build upstream-acceptable infrastructure for the write-rarely case. But, as Julia replied, yes, there's a huge list. :) -Kees -- Kees Cook Nexus Security ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2017-01-04 22:31 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-12-17 1:00 [PATCH] staging: lustre: ldlm: use designated initializers Kees Cook 2016-12-17 1:00 ` [lustre-devel] " Kees Cook 2016-12-19 16:22 ` James Simmons 2016-12-19 16:22 ` [lustre-devel] " James Simmons 2016-12-19 16:47 ` Bruce Korb 2016-12-19 16:48 ` [lustre-devel] " Bruce Korb 2016-12-19 17:12 ` James Simmons 2016-12-19 17:12 ` [lustre-devel] " James Simmons 2016-12-20 7:10 ` Dan Carpenter 2016-12-20 7:10 ` [lustre-devel] " Dan Carpenter 2016-12-20 14:57 ` Hammond, John 2016-12-20 14:57 ` [lustre-devel] " Hammond, John 2016-12-20 16:47 ` Bruce Korb 2016-12-20 16:48 ` [lustre-devel] " Bruce Korb 2016-12-20 18:52 ` Dan Carpenter 2016-12-20 18:52 ` [lustre-devel] " Dan Carpenter 2016-12-20 19:07 ` Dan Carpenter 2016-12-20 19:07 ` [lustre-devel] " Dan Carpenter 2016-12-20 19:46 ` Kees Cook 2016-12-20 19:46 ` [lustre-devel] " Kees Cook 2016-12-19 16:50 ` Patrick Farrell 2016-12-19 17:11 ` James Simmons 2016-12-19 17:11 ` James Simmons 2016-12-20 10:40 ` Dan Carpenter 2016-12-20 10:40 ` [lustre-devel] " Dan Carpenter 2016-12-20 17:29 ` Designated initializers, struct randomization and addressing? Joe Perches 2016-12-20 17:29 ` [lustre-devel] " Joe Perches 2017-01-03 23:47 ` Kees Cook 2017-01-03 23:55 ` Bruce Korb 2017-01-04 0:13 ` Kees Cook 2017-01-04 6:27 ` Julia Lawall 2017-01-04 6:35 ` Kees Cook 2017-01-04 16:55 ` Stephen Hemminger 2017-01-04 17:37 ` Julia Lawall 2017-01-04 22:30 ` Kees Cook
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.