[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CO6PR18MB387393B1CEA068893904535EB06B9@CO6PR18MB3873.namprd18.prod.outlook.com>
Date: Tue, 16 Mar 2021 16:51:28 +0000
From: Stefan Chulski <stefanc@...vell.com>
To: Russell King - ARM Linux admin <linux@...linux.org.uk>
CC: Andrew Lunn <andrew@...n.ch>, "kuba@...nel.org" <kuba@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
"davem@...emloft.net" <davem@...emloft.net>,
Nadav Haklai <nadavh@...vell.com>,
Yan Markman <ymarkman@...vell.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mw@...ihalf.com" <mw@...ihalf.com>,
"atenart@...nel.org" <atenart@...nel.org>,
"rabeeh@...id-run.com" <rabeeh@...id-run.com>
Subject: RE: [EXT] Re: [V2 net-next] net: mvpp2: Add reserved port private
flag configuration
> I really, really hope that someone has thought this through:
>
> Packet Processor I/O Interface (PPIO)
>
> The MUSDK PPIO driver provides low-level network interface API for
> User-Space network drivers/applications. The PPIO infrastrcuture maps
> Marvell's Packet Processor (PPv2) configuration space and I/O descriptors
> space directly to user-space memory. This allows user-space
> driver/application to directly process the packet processor I/O rings from
> user space, without any overhead of a copy operation.
>
> I realy, really hope that you are not exposing the I/O descriptors to
> userspace, allowing userspace to manipulate the physical addresses in those
> descriptors, and that userspace is not dealing with physical addresses.
>
> If userspace has access to the I/O descriptors with physical addresses, or
> userspace is dealing with physical addresses, then you can say good bye to
> any kind of security on the platform. Essentially, in such a scenario, the entire
> system memory becomes accessible to userspace, which includes the kernel.
Hi Russel,
This patch doesn't relate to MUSDK Packet Processor I/O Interface functionality.
MUSDK is just another possible use case I could think of for the port reservation feature.
I am not responsible for the MUSDK code, but as far as I know it is based on the generic UIO Kernel interface (uio_pdrv_genirq) so the user can decide whether he wants to enable it or not for his platform.
For the main CM3 management port use case, security is not an issue since the CM3 processor is secured by hardware in the device and its code is authenticated.
Stefan.
Powered by blists - more mailing lists