linux-kernel - [RFC v2 0/2] vmxnet3: Fix inconsistent DMA accesses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20241119221353.3912257-1-bjohannesmeyer@gmail.com>
Date: Tue, 19 Nov 2024 23:13:51 +0100
From: Brian Johannesmeyer <bjohannesmeyer@...il.com>
To: Ronak Doshi <ronak.doshi@...adcom.com>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Cc: Brian Johannesmeyer <bjohannesmeyer@...il.com>,
	Raphael Isemann <teemperor@...il.com>,
	Cristiano Giuffrida <giuffrida@...vu.nl>,
	Herbert Bos <h.j.bos@...nl>
Subject: [RFC v2 0/2] vmxnet3: Fix inconsistent DMA accesses

We identified hundreds of inconsistent DMA accesses in the VMXNET3 driver,
stemming from the handling of the `adapter` object. This RFC patch series
proposes two alternative fixes for this issue. For an overview of rules
related to streaming DMA access (violations of which lead to inconsistent
accesses), see Figure 4a in [0].

*** Issue ***
The inconsistent accesses occur because the `adapter` object is mapped into
streaming DMA, which means it is "owned" by the device. Any subsequent CPU
access to `adapter` without prior synchronization (e.g.,
`dma_sync_single_for_cpu()`) may cause unexpected hardware behaviors.

*** Patch overview ***
This series includes two mutually exclusive patches:

1. **Patch 1**: Apply if `adapter` *should* be mapped to DMA.
    - Adds synchronization operations in `vmxnet3_probe_device()` to ensure
      consistent accesses when initializing `adapter`.
    - Note: This patch does not cover all instances of inconsistent
      accesses, so similar synchronization will need to be applied
throughout the driver where `adapter` is accessed.

2. **Patch 2**: Apply if `adapter` *should not* be mapped to DMA.
    - Removes `adapter` from streaming DMA entirely, preventing any
      potential inconsistent accesses.
    - It is unclear why `adapter` was mapped to DMA in [1], as it did not
      appear to be mapped before this commit. I welcome any insights into
why this change was originally made, as I am not deeply familiar with
VMXNET3 internals.

*** Request for Feedback ***
Only one of these patches should be applied, and I am seeking feedback to
determine which approach is correct. Thank you for your time and feedback.

*** Changes ***
- Changes vs. v1 [2]: Jakub points out that applying both patch 1 *and*
  patch 2 is odd. Thus, I changed the patch series to apply patch 1 *or*
patch 2. I also made other minor fixes based on his reminder to run
checkpatch.

[0] Link: https://www.usenix.org/system/files/sec21-bai.pdf
[1] commit b0eb57cb97e7837ebb746404c2c58c6f536f23fa ("VMXNET3: Add support
for virtual IOMMU")
[2] Link:
https://lore.kernel.org/lkml/20241113200001.3567479-1-bjohannesmeyer@gmail.com/

Brian Johannesmeyer (1):
  vmxnet3: Fix inconsistent DMA accesses in vmxnet3_probe_device()

 drivers/net/vmxnet3/vmxnet3_drv.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

-- 
2.34.1