Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 10 Feb 2017 15:15:24 -0800
From: Kees Cook <keescook@...omium.org>
To: Jessica Frazelle <me@...sfraz.com>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH 1/4] irq: set {msi_domain,syscore}_ops
 as __ro_after_init

On Fri, Feb 10, 2017 at 2:02 PM, Jessica Frazelle <me@...sfraz.com> wrote:
> On Fri, Feb 10, 2017 at 1:55 PM, Kees Cook <keescook@...omium.org> wrote:
>> On Fri, Feb 10, 2017 at 2:08 AM, Jess Frazelle <me@...sfraz.com> wrote:
>>> Marked msi_domain_ops structs as __ro_after_init when called only during init.
>>> Marked syscore_ops structs as __ro_after_init when register_syscore_ops was
>>> called only during init. Most of the caller functions were already annotated as
>>> __init.
>>> This protects the data structure from accidental corruption.
>>>
>>> Suggested-by: Kees Cook <keescook@...omium.org>
>>> Signed-off-by: Jess Frazelle <me@...sfraz.com>
>>> ---
>>>  drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 2 +-
>>>  kernel/irq/generic-chip.c                              | 2 +-
>>>  kernel/irq/msi.c                                       | 2 +-
>>>  kernel/irq/pm.c                                        | 2 +-
>>>  4 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
>>> index 6b1cd574644f..0e2c1b5e13b7 100644
>>> --- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
>>> +++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
>>> @@ -51,7 +51,7 @@ static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain,
>>>         return msi_info->ops->msi_prepare(msi_domain->parent, dev, nvec, info);
>>>  }
>>>
>>> -static struct msi_domain_ops its_fsl_mc_msi_ops = {
>>> +static struct msi_domain_ops its_fsl_mc_msi_ops __ro_after_init = {
>>>         .msi_prepare = its_fsl_mc_msi_prepare,
>>>  };
>>>
>>> diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
>>> index ee32870079c9..cca63dbaabea 100644
>>> --- a/kernel/irq/generic-chip.c
>>> +++ b/kernel/irq/generic-chip.c
>>> @@ -623,7 +623,7 @@ static void irq_gc_shutdown(void)
>>>         }
>>>  }
>>>
>>> -static struct syscore_ops irq_gc_syscore_ops = {
>>> +static struct syscore_ops irq_gc_syscore_ops __ro_after_init = {
>>>         .suspend = irq_gc_suspend,
>>>         .resume = irq_gc_resume,
>>>         .shutdown = irq_gc_shutdown,
>>> diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
>>> index ee230063f033..0e5b723f710f 100644
>>> --- a/kernel/irq/msi.c
>>> +++ b/kernel/irq/msi.c
>>> @@ -217,7 +217,7 @@ static int msi_domain_ops_check(struct irq_domain *domain,
>>>         return 0;
>>>  }
>>>
>>> -static struct msi_domain_ops msi_domain_ops_default = {
>>> +static struct msi_domain_ops msi_domain_ops_default __ro_after_init = {
>>>         .get_hwirq      = msi_domain_ops_get_hwirq,
>>>         .msi_init       = msi_domain_ops_init,
>>>         .msi_check      = msi_domain_ops_check,
>>> diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
>>> index cea1de0161f1..d6b889bed323 100644
>>> --- a/kernel/irq/pm.c
>>> +++ b/kernel/irq/pm.c
>>> @@ -185,7 +185,7 @@ static void irq_pm_syscore_resume(void)
>>>         resume_irqs(true);
>>>  }
>>>
>>> -static struct syscore_ops irq_pm_syscore_ops = {
>>> +static struct syscore_ops irq_pm_syscore_ops __ro_after_init = {
>>>         .resume         = irq_pm_syscore_resume,
>>>  };
>>
>> Cool! How'd you end up choosing these? Did you just go looking for
>> one-sided initializations? (i.e. register_syscore_ops() without
>> unregister_syscore_ops() call?)
>
> I first made the mistake of making them all __ro_after_init and I
> broke the kvm module, so I had to track down how that happened since I
> didn't touch that code path... I ended up digging a bit into the call
> stack that ultimately leads to these and this is my initial "safe
> set". I am still digging into the others. But almost all the functions
> that call `syscore_ops` structs were already marked as __init.

Right, the danger is if something outside of __init tries to change
the structure, but none of these seem to ever have an UNregister call
made against them. :)

>> (It may help the commit message to explicitly state that
>> unregister_syscore_ops() is never called on these ops.)
>
> Will fix!

Awesome. :)

-Kees

-- 
Kees Cook
Pixel Security

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.