From: Leon Romanovsky <leon@kernel.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Marc Zyngier <maz@kernel.org>,
darwi@linutronix.de, elena.reshetova@intel.com,
kirill.shutemov@linux.intel.com,
Mika Westerberg <mika.westerberg@linux.intel.com>,
stable@vger.kernel.org
Subject: Re: [PATCH 1/2] PCI/MSI: Cache the MSIX table size
Date: Tue, 24 Jan 2023 14:59:40 +0200 [thread overview]
Message-ID: <Y8/WPAqZACAHcmf+@unreal> (raw)
In-Reply-To: <87pmb4p0ik.fsf@ubik.fi.intel.com>
On Tue, Jan 24, 2023 at 02:42:11PM +0200, Alexander Shishkin wrote:
> Leon Romanovsky <leon@kernel.org> writes:
>
> > On Tue, Jan 24, 2023 at 01:52:37PM +0200, Alexander Shishkin wrote:
> >> Leon Romanovsky <leon@kernel.org> writes:
> >>
> >> > I'm not security expert here, but not sure that this protects from anything.
> >> > 1. Kernel relies on working and not-malicious HW. There are gazillion ways
> >> > to cause crashes other than changing MSI-X.
> >>
> >> This particular bug was preventing our fuzzing from going deeper into
> >> the code and reaching some more of the aforementioned gazillion bugs.
> >
> > Your commit message says nothing about fuzzing, but talks about
> > malicious device.
>
> A malicious device is what the fuzzing is aiming to simulate. The fact
> of fuzzing process itself didn't seem relevant to the patch, so I didn't
> include it, going instead for the problem statement and proposed
> solution. Will the commit message benefit from mentioning fuzzing?
No, for most if not all kernel developers, the fuzzing means some sort of
random user-space input. PCI devices are trusted in the kernel.
>
> > Do you see "gazillion bugs" for devices which don't change their MSI-X
> > table size under the hood, which is main kernel assumption?
>
> Not so far.
So please share them with us.
>
> > If yes, you should fix these bugs.
>
> That's absolutely the intention.
So let's fix the bugs and not hide them.
>
> >> > 2. Device can report large table size, kernel will cache it and
> >> > malicious device will reduce it back. It is not handled and will cause
> >> > to kernel crash too.
> >>
> >> How would that happen? If the device decides to have fewer vectors,
> >> they'll all still fit in the ioremapped MSIX table. The worst thing that
> >> can happen is 0xffffffff reads from the mmio space, which a device can
> >> do anyway. But that shouldn't trigger a page fault or otherwise
> >> crash. Or am I missing something?
> >
> > Like I said, I'm no expert. You should tell me if it safe for all
> > callers of pci_msix_vec_count().
>
> Well, since you stated that the reverse will cause a kernel crash, I had
> to ask how. I'll include some version of the above paragraph in the
> commit message to indicate that we reverse situation has been considered.
Not really. I didn't see any explanation how will it work if number
of vectors (which MSI-X table represents) is completely different from
seeing by PCI core.
Thanks
>
> Regards,
> --
> Alex
next prev parent reply other threads:[~2023-01-24 13:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-19 17:06 [PATCH 0/2] PCI/MSI: Hardening fixes Alexander Shishkin
2023-01-19 17:06 ` [PATCH 1/2] PCI/MSI: Cache the MSIX table size Alexander Shishkin
2023-01-22 9:00 ` Leon Romanovsky
2023-01-22 10:57 ` Marc Zyngier
2023-01-22 15:34 ` David Laight
2023-01-24 11:59 ` Alexander Shishkin
2023-01-22 10:57 ` Greg KH
2023-01-23 10:22 ` Jonathan Cameron
2023-01-24 11:52 ` Alexander Shishkin
2023-01-24 12:10 ` Leon Romanovsky
2023-01-24 12:42 ` Alexander Shishkin
2023-01-24 12:59 ` Leon Romanovsky [this message]
2023-01-24 15:28 ` Alexander Shishkin
2023-01-24 15:32 ` Greg KH
2023-01-25 12:33 ` Reshetova, Elena
2023-01-19 17:06 ` [PATCH 2/2] PCI/MSI: Validate device supplied MSI table offset and size Alexander Shishkin
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=Y8/WPAqZACAHcmf+@unreal \
--to=leon@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=darwi@linutronix.de \
--cc=elena.reshetova@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=maz@kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=stable@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).