All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Jess Frazelle <me@jessfraz.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Keith Busch <keith.busch@intel.com>,
	"open list:Hyper-V CORE AND DRIVERS"
	<devel@linuxdriverproject.org>,
	"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	kernel-hardening@lists.openwall.com,
	Kees Cook <keescook@chromium.org>,
	Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [PATCH v2 3/5] pci: set msi_domain_ops as __ro_after_init
Date: Thu, 16 Feb 2017 08:35:10 -0600	[thread overview]
Message-ID: <20170216143509.GA22820@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1702152143520.3805@nanos>

On Wed, Feb 15, 2017 at 10:16:32PM +0100, Thomas Gleixner wrote:

> I think I suggested to Jiang to do that 'update with default functions' to
> 
> - avoid exporting the world and some more
> 
> - have the flexibility to add new functions to the ops w/o updating a
>   gazillion of existing usage sites, which has saved us lots of chaising in
>   the last years
> 
> - avoid the if (ops->ptr) ops->ptr(); else default_fn(); constructs all
>   over the place.
> 
> I admit I did not think about the fact that this makes the structs non
> const.
> 
> Mopping that up by exporting the default functions and setting all the
> function pointers is tedious and requires a full tree sweep when we add new
> stuff. There's also code shared between PCI/platform/DT based stuff, so
> that becomes interesting.

It's legal to initialize a field multiple times, and the last one
takes precedence, so doing this might at least avoid the full tree
sweeps:

  static struct msi_domain_ops vmd_msi_domain_ops = {
    MSI_DOMAIN_DEFAULT_OPS,
    .get_hwirq = vmd_get_hwirq,
  };

The functions referenced by MSI_DOMAIN_DEFAULT_OPS would still have to
be exported, though.

> Doing the if (ops->ptr) ops->ptr() else default_fn(); dance should be
> simpler to pull off. There are not that many sites to look at, but then we
> have some of the GICv3 code using the domain ops out of core.
> 
> For now doing the __ro_after_init is definitely the simplest and fastest
> solution to tighten these statically allocated structures.

I'm OK with __ro_after_init, at least as an interim solution.

I do think it would be good to audit all the uses of
MSI_FLAG_USE_DEF_DOM_OPS and MSI_FLAG_USE_DEF_CHIP_OPS, since they
seem to be the primary indicator of when the struct might be modified.
I suspect we could add __ro_after_init to more than just pci-hyperv.c,
vmd.c, and msi.c

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Jess Frazelle <me@jessfraz.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Keith Busch <keith.busch@intel.com>,
	"open list:Hyper-V CORE AND DRIVERS"
	<devel@linuxdriverproject.org>,
	"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	kernel-hardening@lists.openwall.com,
	Kees Cook <keescook@chromium.org>,
	Marc Zyngier <marc.zyngier@arm.com>
Subject: [kernel-hardening] Re: [PATCH v2 3/5] pci: set msi_domain_ops as __ro_after_init
Date: Thu, 16 Feb 2017 08:35:10 -0600	[thread overview]
Message-ID: <20170216143509.GA22820@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1702152143520.3805@nanos>

On Wed, Feb 15, 2017 at 10:16:32PM +0100, Thomas Gleixner wrote:

> I think I suggested to Jiang to do that 'update with default functions' to
> 
> - avoid exporting the world and some more
> 
> - have the flexibility to add new functions to the ops w/o updating a
>   gazillion of existing usage sites, which has saved us lots of chaising in
>   the last years
> 
> - avoid the if (ops->ptr) ops->ptr(); else default_fn(); constructs all
>   over the place.
> 
> I admit I did not think about the fact that this makes the structs non
> const.
> 
> Mopping that up by exporting the default functions and setting all the
> function pointers is tedious and requires a full tree sweep when we add new
> stuff. There's also code shared between PCI/platform/DT based stuff, so
> that becomes interesting.

It's legal to initialize a field multiple times, and the last one
takes precedence, so doing this might at least avoid the full tree
sweeps:

  static struct msi_domain_ops vmd_msi_domain_ops = {
    MSI_DOMAIN_DEFAULT_OPS,
    .get_hwirq = vmd_get_hwirq,
  };

The functions referenced by MSI_DOMAIN_DEFAULT_OPS would still have to
be exported, though.

> Doing the if (ops->ptr) ops->ptr() else default_fn(); dance should be
> simpler to pull off. There are not that many sites to look at, but then we
> have some of the GICv3 code using the domain ops out of core.
> 
> For now doing the __ro_after_init is definitely the simplest and fastest
> solution to tighten these statically allocated structures.

I'm OK with __ro_after_init, at least as an interim solution.

I do think it would be good to audit all the uses of
MSI_FLAG_USE_DEF_DOM_OPS and MSI_FLAG_USE_DEF_CHIP_OPS, since they
seem to be the primary indicator of when the struct might be modified.
I suspect we could add __ro_after_init to more than just pci-hyperv.c,
vmd.c, and msi.c

Bjorn

  reply	other threads:[~2017-02-16 14:35 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-11  1:37 [PATCH v2 1/5] irq: set {msi_domain,syscore}_ops as __ro_after_init Jess Frazelle
2017-02-11  1:37 ` [kernel-hardening] " Jess Frazelle
2017-02-11  1:37 ` [PATCH v2 2/5] time: mark syscore_ops " Jess Frazelle
2017-02-11  1:37   ` [kernel-hardening] " Jess Frazelle
2017-02-11  2:12   ` John Stultz
2017-02-11  2:12     ` [kernel-hardening] " John Stultz
2017-02-11  9:23     ` Thomas Gleixner
2017-02-11  9:23       ` [kernel-hardening] " Thomas Gleixner
2017-02-11  1:37 ` [PATCH v2 3/5] pci: set msi_domain_ops " Jess Frazelle
2017-02-11  1:37   ` [kernel-hardening] " Jess Frazelle
2017-02-12  4:08   ` KY Srinivasan
2017-02-12  4:08     ` [kernel-hardening] " KY Srinivasan
2017-02-12  4:08     ` KY Srinivasan
2017-02-13 18:14   ` Keith Busch
2017-02-13 18:14     ` [kernel-hardening] " Keith Busch
2017-02-15 20:33   ` Bjorn Helgaas
2017-02-15 20:33     ` [kernel-hardening] " Bjorn Helgaas
2017-02-15 20:46     ` Kees Cook
2017-02-15 20:46       ` [kernel-hardening] " Kees Cook
2017-02-15 20:46       ` Kees Cook
2017-02-15 21:16     ` Thomas Gleixner
2017-02-15 21:16       ` [kernel-hardening] " Thomas Gleixner
2017-02-16 14:35       ` Bjorn Helgaas [this message]
2017-02-16 14:35         ` Bjorn Helgaas
2017-02-16 14:38         ` Thomas Gleixner
2017-02-16 14:38           ` [kernel-hardening] " Thomas Gleixner
2017-03-07 19:07           ` Bjorn Helgaas
2017-03-07 19:07             ` [kernel-hardening] " Bjorn Helgaas
2017-03-14 18:50             ` Jessica Frazelle
2017-03-14 18:50               ` [kernel-hardening] " Jessica Frazelle
2017-03-14 19:24               ` Bjorn Helgaas
2017-03-14 19:24                 ` [kernel-hardening] " Bjorn Helgaas
2017-02-11  1:37 ` [PATCH v2 4/5] staging: " Jess Frazelle
2017-02-11  1:37   ` [kernel-hardening] " Jess Frazelle
2017-02-11  1:37 ` [PATCH v2 5/5] x86: " Jess Frazelle
2017-02-11  1:37   ` [kernel-hardening] " Jess Frazelle
2017-02-11  9:14 ` [PATCH v2 1/5] irq: set {msi_domain,syscore}_ops " Thomas Gleixner
2017-02-11  9:14   ` [kernel-hardening] " Thomas Gleixner
2017-02-11  9:23   ` Thomas Gleixner
2017-02-11  9:23     ` [kernel-hardening] " Thomas Gleixner
2017-02-11 10:48   ` Jess Frazelle
2017-02-11 10:48     ` [kernel-hardening] " Jess Frazelle
2017-02-11 12:00     ` Thomas Gleixner
2017-02-11 12:00       ` [kernel-hardening] " Thomas Gleixner
2017-02-11 12:17       ` Jessica Frazelle
2017-02-11 12:17         ` [kernel-hardening] " Jessica Frazelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170216143509.GA22820@bhelgaas-glaptop.roam.corp.google.com \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=devel@linuxdriverproject.org \
    --cc=haiyangz@microsoft.com \
    --cc=keescook@chromium.org \
    --cc=keith.busch@intel.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kys@microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=me@jessfraz.com \
    --cc=sthemmin@microsoft.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.