From: Thomas Gleixner <tglx@linutronix.de>
To: Bjorn Helgaas <helgaas@kernel.org>
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: Wed, 15 Feb 2017 22:16:32 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1702152143520.3805@nanos> (raw)
In-Reply-To: <20170215203347.GA6981@bhelgaas-glaptop.roam.corp.google.com>
On Wed, 15 Feb 2017, Bjorn Helgaas wrote:
> We know at build-time what all the function pointers will be, so in
> principle we should be able to make the struct const, which would be
> even better than __ro_after_init.
Not everywhere unfortunately. In some instances it's a runtime decision, but
yes, they could be fixed. But there is a downside in doing this. See below.
> For example, we could require that callers set every function pointer
> before calling pci_msi_create_irq_domain(), using the default ones
> (pci_msi_domain_set_desc, pci_msi_domain_check_cap,
> pci_msi_domain_handle_error) if it doesn't need to override them,
> e.g.,
>
> static struct msi_domain_ops vmd_msi_domain_ops = {
> .get_hwirq = vmd_get_hwirq,
> .msi_check = pci_msi_domain_check_cap,
> };
>
> Or we could leave NULL pointers in the structure and have the code
> that calls through the function pointers check for NULL and call the
> default itself, e.g.,
>
> if (ops->msi_check)
> ops->msi_check(...)
> else
> pci_msi_domain_check_cap(...)
>
> It looks like the "USE_DEF_OPS" framework was added by Jiang Liu with
> the commits below. I would CC: him for his thoughts, but I don't
> have a current email address.
Me neither :(
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.
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 have a look with Marc, what can be done in the long run.
Thanks,
tglx
next prev parent reply other threads:[~2017-02-15 21:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-11 1:37 [kernel-hardening] [PATCH v2 1/5] irq: set {msi_domain,syscore}_ops as __ro_after_init Jess Frazelle
2017-02-11 1:37 ` [kernel-hardening] [PATCH v2 2/5] time: mark syscore_ops " Jess Frazelle
2017-02-11 2:12 ` [kernel-hardening] " John Stultz
2017-02-11 9:23 ` Thomas Gleixner
2017-02-11 1:37 ` [kernel-hardening] [PATCH v2 3/5] pci: set msi_domain_ops " Jess Frazelle
2017-02-12 4:08 ` [kernel-hardening] " KY Srinivasan
2017-02-13 18:14 ` [kernel-hardening] " Keith Busch
2017-02-15 20:33 ` Bjorn Helgaas
2017-02-15 20:46 ` Kees Cook
2017-02-15 21:16 ` Thomas Gleixner [this message]
2017-02-16 14:35 ` Bjorn Helgaas
2017-02-16 14:38 ` Thomas Gleixner
2017-03-07 19:07 ` Bjorn Helgaas
2017-03-14 18:50 ` Jessica Frazelle
2017-03-14 19:24 ` Bjorn Helgaas
2017-02-11 1:37 ` [kernel-hardening] [PATCH v2 4/5] staging: " Jess Frazelle
2017-02-11 1:37 ` [kernel-hardening] [PATCH v2 5/5] x86: " Jess Frazelle
2017-02-11 9:14 ` [kernel-hardening] Re: [PATCH v2 1/5] irq: set {msi_domain,syscore}_ops " Thomas Gleixner
2017-02-11 9:23 ` Thomas Gleixner
2017-02-11 10:48 ` Jess Frazelle
2017-02-11 12:00 ` Thomas Gleixner
2017-02-11 12:17 ` 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=alpine.DEB.2.20.1702152143520.3805@nanos \
--to=tglx@linutronix.de \
--cc=bhelgaas@google.com \
--cc=devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=helgaas@kernel.org \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox