| Message ID | 20221017162807.1692691-1-sean.anderson@seco.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net] net: fman: Use physical address for userspace interfaces | expand |
> -----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>
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
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
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
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
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
> -----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&data=05%7C01%7Cmadalin.bucur%40nxp.com%7Cb35d8b37f9224e4b793408dab > 1525b5a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638017264524356126%7 > CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW > wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BcoXaNNlcqzKLsGC5WKuk8Mwette > D51cCbzJvHfG7Vs%3D&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
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
> > 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
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 --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;
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(-)