diff mbox series

[net] net: fman: Use physical address for userspace interfaces

Message ID 20221017162807.1692691-1-sean.anderson@seco.com
State New
Headers
Series [net] net: fman: Use physical address for userspace interfaces |

Commit Message

Sean Anderson Oct. 17, 2022, 4:28 p.m. UTC 
  For whatever reason, the address of the MAC is exposed to userspace in
several places. We need to use the physical address for this purpose to
avoid leaking information about the kernel's memory layout, and to keep
backwards compatibility.

Fixes: 262f2b782e25 ("net: fman: Map the base address once")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---

 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c       |  4 ++--
 drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c |  2 +-
 drivers/net/ethernet/freescale/fman/mac.c            | 12 ++++++------
 drivers/net/ethernet/freescale/fman/mac.h            |  2 +-
 4 files changed, 10 insertions(+), 10 deletions(-)

Comments

Madalin Bucur Oct. 18, 2022, 6:45 a.m. UTC | #1 
> -----Original Message-----
> From: Sean Anderson <sean.anderson@seco.com>
> Sent: 17 October 2022 19:28
> To: David S . Miller <davem@davemloft.net>; netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Madalin Bucur <madalin.bucur@nxp.com>;
> Jakub Kicinski <kuba@kernel.org>; Eric Dumazet <edumazet@google.com>;
> Paolo Abeni <pabeni@redhat.com>; Camelia Alexandra Groza
> <camelia.groza@nxp.com>; Geert Uytterhoeven <geert@linux-m68k.org>; Sean
> Anderson <sean.anderson@seco.com>
> Subject: [PATCH net] net: fman: Use physical address for userspace
> interfaces
> 
> For whatever reason, the address of the MAC is exposed to userspace in
> several places. We need to use the physical address for this purpose to
> avoid leaking information about the kernel's memory layout, and to keep
> backwards compatibility.
> 
> Fixes: 262f2b782e25 ("net: fman: Map the base address once")
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Sean Anderson <sean.anderson@seco.com>
> ---
> 
>  drivers/net/ethernet/freescale/dpaa/dpaa_eth.c       |  4 ++--
>  drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c |  2 +-
>  drivers/net/ethernet/freescale/fman/mac.c            | 12 ++++++------
>  drivers/net/ethernet/freescale/fman/mac.h            |  2 +-
>  4 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index 31cfa121333d..fc68a32ce2f7 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -221,8 +221,8 @@ static int dpaa_netdev_init(struct net_device *net_dev,
>  	net_dev->netdev_ops = dpaa_ops;
>  	mac_addr = mac_dev->addr;
> 
> -	net_dev->mem_start = (unsigned long)mac_dev->vaddr;
> -	net_dev->mem_end = (unsigned long)mac_dev->vaddr_end;
> +	net_dev->mem_start = (unsigned long)priv->mac_dev->res->start;
> +	net_dev->mem_end = (unsigned long)priv->mac_dev->res->end;
> 
>  	net_dev->min_mtu = ETH_MIN_MTU;
>  	net_dev->max_mtu = dpaa_get_max_mtu();
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c
> index 258eb6c8f4c0..4fee74c024bd 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c
> @@ -18,7 +18,7 @@ static ssize_t dpaa_eth_show_addr(struct device *dev,
> 
>  	if (mac_dev)
>  		return sprintf(buf, "%llx",
> -				(unsigned long long)mac_dev->vaddr);
> +				(unsigned long long)mac_dev->res->start);
>  	else
>  		return sprintf(buf, "none");
>  }
> diff --git a/drivers/net/ethernet/freescale/fman/mac.c
> b/drivers/net/ethernet/freescale/fman/mac.c
> index 7b7526fd7da3..65df308bad97 100644
> --- a/drivers/net/ethernet/freescale/fman/mac.c
> +++ b/drivers/net/ethernet/freescale/fman/mac.c
> @@ -279,7 +279,6 @@ static int mac_probe(struct platform_device *_of_dev)
>  	struct device_node	*mac_node, *dev_node;
>  	struct mac_device	*mac_dev;
>  	struct platform_device	*of_dev;
> -	struct resource		*res;
>  	struct mac_priv_s	*priv;
>  	struct fman_mac_params	 params;
>  	u32			 val;
> @@ -338,24 +337,25 @@ static int mac_probe(struct platform_device *_of_dev)
>  	of_node_put(dev_node);
> 
>  	/* Get the address of the memory mapped registers */
> -	res = platform_get_mem_or_io(_of_dev, 0);
> -	if (!res) {
> +	mac_dev->res = platform_get_mem_or_io(_of_dev, 0);
> +	if (!mac_dev->res) {
>  		dev_err(dev, "could not get registers\n");
>  		return -EINVAL;
>  	}
> 
> -	err = devm_request_resource(dev, fman_get_mem_region(priv->fman),
> res);
> +	err = devm_request_resource(dev, fman_get_mem_region(priv->fman),
> +				    mac_dev->res);
>  	if (err) {
>  		dev_err_probe(dev, err, "could not request resource\n");
>  		return err;
>  	}
> 
> -	mac_dev->vaddr = devm_ioremap(dev, res->start, resource_size(res));
> +	mac_dev->vaddr = devm_ioremap(dev, mac_dev->res->start,
> +				      resource_size(mac_dev->res));
>  	if (!mac_dev->vaddr) {
>  		dev_err(dev, "devm_ioremap() failed\n");
>  		return -EIO;
>  	}
> -	mac_dev->vaddr_end = mac_dev->vaddr + resource_size(res);
> 
>  	if (!of_device_is_available(mac_node))
>  		return -ENODEV;
> diff --git a/drivers/net/ethernet/freescale/fman/mac.h
> b/drivers/net/ethernet/freescale/fman/mac.h
> index b95d384271bd..13b69ca5f00c 100644
> --- a/drivers/net/ethernet/freescale/fman/mac.h
> +++ b/drivers/net/ethernet/freescale/fman/mac.h
> @@ -20,8 +20,8 @@ struct mac_priv_s;
> 
>  struct mac_device {
>  	void __iomem		*vaddr;
> -	void __iomem		*vaddr_end;
>  	struct device		*dev;
> +	struct resource		*res;
>  	u8			 addr[ETH_ALEN];
>  	struct fman_port	*port[2];
>  	u32			 if_support;
> --
> 2.35.1.1320.gc452695387.dirty

Thanks for the fix,

Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
Andrew Lunn Oct. 18, 2022, 5:22 p.m. UTC | #2 
On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote:
> For whatever reason, the address of the MAC is exposed to userspace in
> several places. We need to use the physical address for this purpose to
> avoid leaking information about the kernel's memory layout, and to keep
> backwards compatibility.

How does this keep backwards compatibility? Whatever is in user space
using this virtual address expects a virtual address. If it now gets a
physical address it will probably do the wrong thing. Unless there is
a one to one mapping, and you are exposing virtual addresses anyway.

If you are going to break backwards compatibility Maybe it would be
better to return 0xdeadbeef? Or 0?

       Andrew
Sean Anderson Oct. 18, 2022, 5:37 p.m. UTC | #3 
Hi Andrew,

On 10/18/22 1:22 PM, Andrew Lunn wrote:
> On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote:
>> For whatever reason, the address of the MAC is exposed to userspace in
>> several places. We need to use the physical address for this purpose to
>> avoid leaking information about the kernel's memory layout, and to keep
>> backwards compatibility.
> 
> How does this keep backwards compatibility? Whatever is in user space
> using this virtual address expects a virtual address. If it now gets a
> physical address it will probably do the wrong thing. Unless there is
> a one to one mapping, and you are exposing virtual addresses anyway.
> 
> If you are going to break backwards compatibility Maybe it would be
> better to return 0xdeadbeef? Or 0?
> 
>        Andrew
> 

The fixed commit was added in v6.1-rc1 and switched from physical to
virtual. So this is effectively a partial revert to the previous
behavior (but keeping the other changes). See [1] for discussion.

--Sean

[1] https://lore.kernel.org/netdev/20220902215737.981341-1-sean.anderson@seco.com/T/#md5c6b66bc229c09062d205352a7d127c02b8d262
Andrew Davis Oct. 18, 2022, 6:33 p.m. UTC | #4 
On 10/18/22 12:37 PM, Sean Anderson wrote:
> Hi Andrew,
> 
> On 10/18/22 1:22 PM, Andrew Lunn wrote:
>> On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote:
>>> For whatever reason, the address of the MAC is exposed to userspace in
>>> several places. We need to use the physical address for this purpose to
>>> avoid leaking information about the kernel's memory layout, and to keep
>>> backwards compatibility.
>>
>> How does this keep backwards compatibility? Whatever is in user space
>> using this virtual address expects a virtual address. If it now gets a
>> physical address it will probably do the wrong thing. Unless there is
>> a one to one mapping, and you are exposing virtual addresses anyway.
>>
>> If you are going to break backwards compatibility Maybe it would be
>> better to return 0xdeadbeef? Or 0?
>>
>>         Andrew
>>
> 
> The fixed commit was added in v6.1-rc1 and switched from physical to
> virtual. So this is effectively a partial revert to the previous
> behavior (but keeping the other changes). See [1] for discussion.
> 
> --Sean
> 
> [1] https://lore.kernel.org/netdev/20220902215737.981341-1-sean.anderson@seco.com/T/#md5c6b66bc229c09062d205352a7d127c02b8d262

I see it asked in that thread, but not answered. Why are you exposing
"physical" addresses to userspace? There should be no reason for that.

Andrew
Andrew Lunn Oct. 18, 2022, 9:39 p.m. UTC | #5 
On Tue, Oct 18, 2022 at 01:33:55PM -0500, Andrew Davis wrote:
> On 10/18/22 12:37 PM, Sean Anderson wrote:
> > Hi Andrew,
> > 
> > On 10/18/22 1:22 PM, Andrew Lunn wrote:
> > > On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote:
> > > > For whatever reason, the address of the MAC is exposed to userspace in
> > > > several places. We need to use the physical address for this purpose to
> > > > avoid leaking information about the kernel's memory layout, and to keep
> > > > backwards compatibility.
> > > 
> > > How does this keep backwards compatibility? Whatever is in user space
> > > using this virtual address expects a virtual address. If it now gets a
> > > physical address it will probably do the wrong thing. Unless there is
> > > a one to one mapping, and you are exposing virtual addresses anyway.
> > > 
> > > If you are going to break backwards compatibility Maybe it would be
> > > better to return 0xdeadbeef? Or 0?
> > > 
> > >         Andrew
> > > 
> > 
> > The fixed commit was added in v6.1-rc1 and switched from physical to
> > virtual. So this is effectively a partial revert to the previous
> > behavior (but keeping the other changes). See [1] for discussion.

Please don't assume a reviewer has seen the previous
discussion. Include the background in the commit message to help such
reviewers.

> > 
> > --Sean
> > 
> > [1] https://lore.kernel.org/netdev/20220902215737.981341-1-sean.anderson@seco.com/T/#md5c6b66bc229c09062d205352a7d127c02b8d262
> 
> I see it asked in that thread, but not answered. Why are you exposing
> "physical" addresses to userspace? There should be no reason for that.

I don't see anything about needing physical or virtual address in the
discussion, or i've missed it.

If nobody knows why it is needed, either use an obfusticated value, or
remove it all together. If somebody/something does need it, they will
report the regression.

       Andrew
Sean Anderson Oct. 18, 2022, 9:47 p.m. UTC | #6 
On 10/18/22 5:39 PM, Andrew Lunn wrote:
> On Tue, Oct 18, 2022 at 01:33:55PM -0500, Andrew Davis wrote:
>> On 10/18/22 12:37 PM, Sean Anderson wrote:
>> > Hi Andrew,
>> > 
>> > On 10/18/22 1:22 PM, Andrew Lunn wrote:
>> > > On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote:
>> > > > For whatever reason, the address of the MAC is exposed to userspace in
>> > > > several places. We need to use the physical address for this purpose to
>> > > > avoid leaking information about the kernel's memory layout, and to keep
>> > > > backwards compatibility.
>> > > 
>> > > How does this keep backwards compatibility? Whatever is in user space
>> > > using this virtual address expects a virtual address. If it now gets a
>> > > physical address it will probably do the wrong thing. Unless there is
>> > > a one to one mapping, and you are exposing virtual addresses anyway.
>> > > 
>> > > If you are going to break backwards compatibility Maybe it would be
>> > > better to return 0xdeadbeef? Or 0?
>> > > 
>> > >         Andrew
>> > > 
>> > 
>> > The fixed commit was added in v6.1-rc1 and switched from physical to
>> > virtual. So this is effectively a partial revert to the previous
>> > behavior (but keeping the other changes). See [1] for discussion.
> 
> Please don't assume a reviewer has seen the previous
> discussion. Include the background in the commit message to help such
> reviewers.
> 
>> > 
>> > --Sean
>> > 
>> > [1] https://lore.kernel.org/netdev/20220902215737.981341-1-sean.anderson@seco.com/T/#md5c6b66bc229c09062d205352a7d127c02b8d262
>> 
>> I see it asked in that thread, but not answered. Why are you exposing
>> "physical" addresses to userspace? There should be no reason for that.
> 
> I don't see anything about needing physical or virtual address in the
> discussion, or i've missed it.

Well, Madalin originally added this, so perhaps she has some insight.

I have no idea why we set the IFMAP stuff, since that seems like it's for
PCMCIA. Not sure about sysfs either. 

> If nobody knows why it is needed, either use an obfusticated value, or
> remove it all together. If somebody/something does need it, they will
> report the regression.

I'd rather apply this (or v2 of this) and then remove the "feature" in
follow-up.

--Sean
Madalin Bucur Oct. 19, 2022, 5:20 a.m. UTC | #7 
> -----Original Message-----
> From: Sean Anderson <sean.anderson@seco.com>
> Sent: 19 October 2022 00:47
> To: Andrew Lunn <andrew@lunn.ch>; Andrew Davis <afd@ti.com>
> Cc: David S . Miller <davem@davemloft.net>; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; Madalin Bucur <madalin.bucur@nxp.com>;
> Jakub Kicinski <kuba@kernel.org>; Eric Dumazet <edumazet@google.com>;
> Paolo Abeni <pabeni@redhat.com>; Camelia Alexandra Groza
> <camelia.groza@nxp.com>; Geert Uytterhoeven <geert@linux-m68k.org>
> Subject: Re: [PATCH net] net: fman: Use physical address for userspace
> interfaces
> 
> 
> 
> On 10/18/22 5:39 PM, Andrew Lunn wrote:
> > On Tue, Oct 18, 2022 at 01:33:55PM -0500, Andrew Davis wrote:
> >> On 10/18/22 12:37 PM, Sean Anderson wrote:
> >> > Hi Andrew,
> >> >
> >> > On 10/18/22 1:22 PM, Andrew Lunn wrote:
> >> > > On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote:
> >> > > > For whatever reason, the address of the MAC is exposed to
> userspace in
> >> > > > several places. We need to use the physical address for this
> purpose to
> >> > > > avoid leaking information about the kernel's memory layout, and
> to keep
> >> > > > backwards compatibility.
> >> > >
> >> > > How does this keep backwards compatibility? Whatever is in user
> space
> >> > > using this virtual address expects a virtual address. If it now
> gets a
> >> > > physical address it will probably do the wrong thing. Unless there
> is
> >> > > a one to one mapping, and you are exposing virtual addresses
> anyway.
> >> > >
> >> > > If you are going to break backwards compatibility Maybe it would
> be
> >> > > better to return 0xdeadbeef? Or 0?
> >> > >
> >> > >         Andrew
> >> > >
> >> >
> >> > The fixed commit was added in v6.1-rc1 and switched from physical to
> >> > virtual. So this is effectively a partial revert to the previous
> >> > behavior (but keeping the other changes). See [1] for discussion.
> >
> > Please don't assume a reviewer has seen the previous
> > discussion. Include the background in the commit message to help such
> > reviewers.
> >
> >> >
> >> > --Sean
> >> >
> >> > [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Fnetdev%2F20220902215737.981341-1-
> sean.anderson%40seco.com%2FT%2F%23md5c6b66bc229c09062d205352a7d127c02b8d2
> 62&amp;data=05%7C01%7Cmadalin.bucur%40nxp.com%7Cb35d8b37f9224e4b793408dab
> 1525b5a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638017264524356126%7
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=%2BcoXaNNlcqzKLsGC5WKuk8Mwette
> D51cCbzJvHfG7Vs%3D&amp;reserved=0
> >>
> >> I see it asked in that thread, but not answered. Why are you exposing
> >> "physical" addresses to userspace? There should be no reason for that.
> >
> > I don't see anything about needing physical or virtual address in the
> > discussion, or i've missed it.
> 
> Well, Madalin originally added this, so perhaps she has some insight.
> 
> I have no idea why we set the IFMAP stuff, since that seems like it's for
> PCMCIA. Not sure about sysfs either.
> 
> > If nobody knows why it is needed, either use an obfusticated value, or
> > remove it all together. If somebody/something does need it, they will
> > report the regression.
> 
> I'd rather apply this (or v2 of this) and then remove the "feature" in
> follow-up.
> 
> --Sean


root@localhost:~# grep 1ae /etc/udev/rules.d/72-fsl-dpaa-persistent-networking.rules
SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae0000", NAME="fm1-mac1"
SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae2000", NAME="fm1-mac2"
SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae4000", NAME="fm1-mac3"
SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae6000", NAME="fm1-mac4"
SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae8000", NAME="fm1-mac5"
SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1aea000", NAME="fm1-mac6"

root@localhost:~# grep 1ae  /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@*/net/fm1-mac*/device_addr
/sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@2/net/fm1-mac3/device_addr:1ae4000
/sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@3/net/fm1-mac4/device_addr:1ae6000
/sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@4/net/fm1-mac5/device_addr:1ae8000
/sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@5/net/fm1-mac6/device_addr:1aea000


Have a great day!

Madalin
Geert Uytterhoeven Oct. 19, 2022, 6:46 a.m. UTC | #8 
Hi Madalin,

On Wed, Oct 19, 2022 at 7:20 AM Madalin Bucur <madalin.bucur@nxp.com> wrote:
> > -----Original Message-----
> > From: Sean Anderson <sean.anderson@seco.com>
> > Sent: 19 October 2022 00:47
> > To: Andrew Lunn <andrew@lunn.ch>; Andrew Davis <afd@ti.com>
> > Cc: David S . Miller <davem@davemloft.net>; netdev@vger.kernel.org;
> > linux-kernel@vger.kernel.org; Madalin Bucur <madalin.bucur@nxp.com>;
> > Jakub Kicinski <kuba@kernel.org>; Eric Dumazet <edumazet@google.com>;
> > Paolo Abeni <pabeni@redhat.com>; Camelia Alexandra Groza
> > <camelia.groza@nxp.com>; Geert Uytterhoeven <geert@linux-m68k.org>
> > Subject: Re: [PATCH net] net: fman: Use physical address for userspace
> > interfaces
> >
> >
> >
> > On 10/18/22 5:39 PM, Andrew Lunn wrote:
> > > On Tue, Oct 18, 2022 at 01:33:55PM -0500, Andrew Davis wrote:
> > >> On 10/18/22 12:37 PM, Sean Anderson wrote:
> > >> > Hi Andrew,
> > >> >
> > >> > On 10/18/22 1:22 PM, Andrew Lunn wrote:
> > >> > > On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote:
> > >> > > > For whatever reason, the address of the MAC is exposed to
> > userspace in
> > >> > > > several places. We need to use the physical address for this
> > purpose to
> > >> > > > avoid leaking information about the kernel's memory layout, and
> > to keep
> > >> > > > backwards compatibility.
> > >> > >
> > >> > > How does this keep backwards compatibility? Whatever is in user
> > space
> > >> > > using this virtual address expects a virtual address. If it now
> > gets a
> > >> > > physical address it will probably do the wrong thing. Unless there
> > is
> > >> > > a one to one mapping, and you are exposing virtual addresses
> > anyway.
> > >> > >
> > >> > > If you are going to break backwards compatibility Maybe it would
> > be
> > >> > > better to return 0xdeadbeef? Or 0?
> > >> > >
> > >> > >         Andrew
> > >> > >
> > >> >
> > >> > The fixed commit was added in v6.1-rc1 and switched from physical to
> > >> > virtual. So this is effectively a partial revert to the previous
> > >> > behavior (but keeping the other changes). See [1] for discussion.
> > >
> > > Please don't assume a reviewer has seen the previous
> > > discussion. Include the background in the commit message to help such
> > > reviewers.

> > >> I see it asked in that thread, but not answered. Why are you exposing
> > >> "physical" addresses to userspace? There should be no reason for that.
> > >
> > > I don't see anything about needing physical or virtual address in the
> > > discussion, or i've missed it.
> >
> > Well, Madalin originally added this, so perhaps she has some insight.
> >
> > I have no idea why we set the IFMAP stuff, since that seems like it's for
> > PCMCIA. Not sure about sysfs either.
> >
> > > If nobody knows why it is needed, either use an obfusticated value, or
> > > remove it all together. If somebody/something does need it, they will
> > > report the regression.
> >
> > I'd rather apply this (or v2 of this) and then remove the "feature" in
> > follow-up.
> >
> > --Sean
>
>
> root@localhost:~# grep 1ae /etc/udev/rules.d/72-fsl-dpaa-persistent-networking.rules
> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae0000", NAME="fm1-mac1"
> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae2000", NAME="fm1-mac2"
> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae4000", NAME="fm1-mac3"
> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae6000", NAME="fm1-mac4"
> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae8000", NAME="fm1-mac5"
> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1aea000", NAME="fm1-mac6"

So you rely on the physical address.
It's a pity this uses a custom sysfs file.
Can't you obtain this information some other way?
Anyway, as this is in use, it became part of the ABI.

> root@localhost:~# grep 1ae  /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@*/net/fm1-mac*/device_addr
> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@2/net/fm1-mac3/device_addr:1ae4000
> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@3/net/fm1-mac4/device_addr:1ae6000
> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@4/net/fm1-mac5/device_addr:1ae8000
> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@5/net/fm1-mac6/device_addr:1aea000


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Andrew Lunn Oct. 19, 2022, 12:49 p.m. UTC | #9 
> > root@localhost:~# grep 1ae /etc/udev/rules.d/72-fsl-dpaa-persistent-networking.rules
> > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae0000", NAME="fm1-mac1"
> > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae2000", NAME="fm1-mac2"
> > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae4000", NAME="fm1-mac3"
> > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae6000", NAME="fm1-mac4"
> > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae8000", NAME="fm1-mac5"
> > SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1aea000", NAME="fm1-mac6"
> 
> So you rely on the physical address.
> It's a pity this uses a custom sysfs file.
> Can't you obtain this information some other way?
> Anyway, as this is in use, it became part of the ABI.

I agree about the ABI thing. Please add this to the commit messages as
a justification.

It would also be good to move user space away from this. You should be
able to use the port id in the place of the physical address. That is
what is used by Ethernet switches etc, in the udev rules for giving
switch ports names.

       Andrew
Sean Anderson Oct. 19, 2022, 3:04 p.m. UTC | #10 
On 10/19/22 02:46, Geert Uytterhoeven wrote:
> Hi Madalin,
> 
> On Wed, Oct 19, 2022 at 7:20 AM Madalin Bucur <madalin.bucur@nxp.com> wrote:
>>> -----Original Message-----
>>> From: Sean Anderson <sean.anderson@seco.com>
>>> Sent: 19 October 2022 00:47
>>> To: Andrew Lunn <andrew@lunn.ch>; Andrew Davis <afd@ti.com>
>>> Cc: David S . Miller <davem@davemloft.net>; netdev@vger.kernel.org;
>>> linux-kernel@vger.kernel.org; Madalin Bucur <madalin.bucur@nxp.com>;
>>> Jakub Kicinski <kuba@kernel.org>; Eric Dumazet <edumazet@google.com>;
>>> Paolo Abeni <pabeni@redhat.com>; Camelia Alexandra Groza
>>> <camelia.groza@nxp.com>; Geert Uytterhoeven <geert@linux-m68k.org>
>>> Subject: Re: [PATCH net] net: fman: Use physical address for userspace
>>> interfaces
>>>
>>>
>>>
>>> On 10/18/22 5:39 PM, Andrew Lunn wrote:
>>>> On Tue, Oct 18, 2022 at 01:33:55PM -0500, Andrew Davis wrote:
>>>>> On 10/18/22 12:37 PM, Sean Anderson wrote:
>>>>>> Hi Andrew,
>>>>>>
>>>>>> On 10/18/22 1:22 PM, Andrew Lunn wrote:
>>>>>>> On Mon, Oct 17, 2022 at 12:28:06PM -0400, Sean Anderson wrote:
>>>>>>>> For whatever reason, the address of the MAC is exposed to
>>> userspace in
>>>>>>>> several places. We need to use the physical address for this
>>> purpose to
>>>>>>>> avoid leaking information about the kernel's memory layout, and
>>> to keep
>>>>>>>> backwards compatibility.
>>>>>>>
>>>>>>> How does this keep backwards compatibility? Whatever is in user
>>> space
>>>>>>> using this virtual address expects a virtual address. If it now
>>> gets a
>>>>>>> physical address it will probably do the wrong thing. Unless there
>>> is
>>>>>>> a one to one mapping, and you are exposing virtual addresses
>>> anyway.
>>>>>>>
>>>>>>> If you are going to break backwards compatibility Maybe it would
>>> be
>>>>>>> better to return 0xdeadbeef? Or 0?
>>>>>>>
>>>>>>>          Andrew
>>>>>>>
>>>>>>
>>>>>> The fixed commit was added in v6.1-rc1 and switched from physical to
>>>>>> virtual. So this is effectively a partial revert to the previous
>>>>>> behavior (but keeping the other changes). See [1] for discussion.
>>>>
>>>> Please don't assume a reviewer has seen the previous
>>>> discussion. Include the background in the commit message to help such
>>>> reviewers.
> 
>>>>> I see it asked in that thread, but not answered. Why are you exposing
>>>>> "physical" addresses to userspace? There should be no reason for that.
>>>>
>>>> I don't see anything about needing physical or virtual address in the
>>>> discussion, or i've missed it.
>>>
>>> Well, Madalin originally added this, so perhaps she has some insight.
>>>
>>> I have no idea why we set the IFMAP stuff, since that seems like it's for
>>> PCMCIA. Not sure about sysfs either.
>>>
>>>> If nobody knows why it is needed, either use an obfusticated value, or
>>>> remove it all together. If somebody/something does need it, they will
>>>> report the regression.
>>>
>>> I'd rather apply this (or v2 of this) and then remove the "feature" in
>>> follow-up.
>>>
>>> --Sean
>>
>>
>> root@localhost:~# grep 1ae /etc/udev/rules.d/72-fsl-dpaa-persistent-networking.rules
>> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae0000", NAME="fm1-mac1"
>> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae2000", NAME="fm1-mac2"
>> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae4000", NAME="fm1-mac3"
>> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae6000", NAME="fm1-mac4"
>> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1ae8000", NAME="fm1-mac5"
>> SUBSYSTEM=="net", DRIVERS=="fsl_dpa*", ATTR{device_addr}=="1aea000", NAME="fm1-mac6"
> 
> So you rely on the physical address.
> It's a pity this uses a custom sysfs file.
> Can't you obtain this information some other way?
> Anyway, as this is in use, it became part of the ABI.

In my udev rules I use ID_PATH. Since this is a devicetree platform, the path name includes
the device address by convention.

--Sean

>> root@localhost:~# grep 1ae  /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@*/net/fm1-mac*/device_addr
>> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@2/net/fm1-mac3/device_addr:1ae4000
>> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@3/net/fm1-mac4/device_addr:1ae6000
>> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@4/net/fm1-mac5/device_addr:1ae8000
>> /sys/devices/platform/soc/soc:fsl,dpaa/soc:fsl,dpaa:ethernet@5/net/fm1-mac6/device_addr:1aea000
> 
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
diff mbox series

Patch

diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 31cfa121333d..fc68a32ce2f7 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -221,8 +221,8 @@  static int dpaa_netdev_init(struct net_device *net_dev,
 	net_dev->netdev_ops = dpaa_ops;
 	mac_addr = mac_dev->addr;
 
-	net_dev->mem_start = (unsigned long)mac_dev->vaddr;
-	net_dev->mem_end = (unsigned long)mac_dev->vaddr_end;
+	net_dev->mem_start = (unsigned long)priv->mac_dev->res->start;
+	net_dev->mem_end = (unsigned long)priv->mac_dev->res->end;
 
 	net_dev->min_mtu = ETH_MIN_MTU;
 	net_dev->max_mtu = dpaa_get_max_mtu();
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c
index 258eb6c8f4c0..4fee74c024bd 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth_sysfs.c
@@ -18,7 +18,7 @@  static ssize_t dpaa_eth_show_addr(struct device *dev,
 
 	if (mac_dev)
 		return sprintf(buf, "%llx",
-				(unsigned long long)mac_dev->vaddr);
+				(unsigned long long)mac_dev->res->start);
 	else
 		return sprintf(buf, "none");
 }
diff --git a/drivers/net/ethernet/freescale/fman/mac.c b/drivers/net/ethernet/freescale/fman/mac.c
index 7b7526fd7da3..65df308bad97 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -279,7 +279,6 @@  static int mac_probe(struct platform_device *_of_dev)
 	struct device_node	*mac_node, *dev_node;
 	struct mac_device	*mac_dev;
 	struct platform_device	*of_dev;
-	struct resource		*res;
 	struct mac_priv_s	*priv;
 	struct fman_mac_params	 params;
 	u32			 val;
@@ -338,24 +337,25 @@  static int mac_probe(struct platform_device *_of_dev)
 	of_node_put(dev_node);
 
 	/* Get the address of the memory mapped registers */
-	res = platform_get_mem_or_io(_of_dev, 0);
-	if (!res) {
+	mac_dev->res = platform_get_mem_or_io(_of_dev, 0);
+	if (!mac_dev->res) {
 		dev_err(dev, "could not get registers\n");
 		return -EINVAL;
 	}
 
-	err = devm_request_resource(dev, fman_get_mem_region(priv->fman), res);
+	err = devm_request_resource(dev, fman_get_mem_region(priv->fman),
+				    mac_dev->res);
 	if (err) {
 		dev_err_probe(dev, err, "could not request resource\n");
 		return err;
 	}
 
-	mac_dev->vaddr = devm_ioremap(dev, res->start, resource_size(res));
+	mac_dev->vaddr = devm_ioremap(dev, mac_dev->res->start,
+				      resource_size(mac_dev->res));
 	if (!mac_dev->vaddr) {
 		dev_err(dev, "devm_ioremap() failed\n");
 		return -EIO;
 	}
-	mac_dev->vaddr_end = mac_dev->vaddr + resource_size(res);
 
 	if (!of_device_is_available(mac_node))
 		return -ENODEV;
diff --git a/drivers/net/ethernet/freescale/fman/mac.h b/drivers/net/ethernet/freescale/fman/mac.h
index b95d384271bd..13b69ca5f00c 100644
--- a/drivers/net/ethernet/freescale/fman/mac.h
+++ b/drivers/net/ethernet/freescale/fman/mac.h
@@ -20,8 +20,8 @@  struct mac_priv_s;
 
 struct mac_device {
 	void __iomem		*vaddr;
-	void __iomem		*vaddr_end;
 	struct device		*dev;
+	struct resource		*res;
 	u8			 addr[ETH_ALEN];
 	struct fman_port	*port[2];
 	u32			 if_support;