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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9e967bb2-ac46-fc1c-ac3a-ed527c6a4cb5@intel.com>
Date:   Wed, 12 Oct 2022 14:40:14 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Fenghua Yu <fenghua.yu@...el.com>, Vinod Koul <vkoul@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sasha Levin <sashal@...nel.org>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Lu Baolu <baolu.lu@...ux.intel.com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>
Cc:     dmaengine@...r.kernel.org, stable@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dmaengine: idxd: Do not enable user type Work Queue
 without Shared Virtual Addressing

On 10/12/22 13:14, Fenghua Yu wrote:
> Userspace can directly access physical address through user type
> Work Queue (WQ) in two scenarios: no IOMMU or IOMMU Passthrough
> without Shared Virtual Addressing (SVA). In these two cases, user type WQ
> allows userspace to issue DMA physical address access without virtual
> to physical translation.
> 
> This is inconsistent with the security goals of a good kernel API.
> 
> Plus there is no usage for user type WQ without SVA.
> 
> So enable user type WQ only when SVA is enabled (i.e. user PASID is
> enabled).

I'm not sure the changelog here is great.

The whole "user Work Queue" thing is an entire *DRIVER*.  So, this
really has zero to do with the type of workqueue and everything to do
with the kind of drivers we allow to be loaded and drive the hardware.

Basically, the *hardware* allows pretty arbitrary direct access to
physical memory.  The 'idxd_user_drv' driver code (including
idxd_user_drv_probe()) gives low-level, direct access to the hardware,
which is bad news.

Plus, even if userspace got access to the device via this driver, they
have to feel physical addresses to it, which is generally not easy from
userspace.

That's as close as I can get to rephrasing the above TLA soup in plain
old English.

I also detest the "There is no usage case for the WQ without SVA."
language.  Those words lack meaning.  There has to be a *REASON* there
is no use case.  Please think about what those words *mean*, then delete
them and write what they mean.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ