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 <[email protected]>
Signed-off-by: Sean Anderson <[email protected]>
---
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
> -----Original Message-----
> From: Sean Anderson <[email protected]>
> Sent: 17 October 2022 19:28
> To: David S . Miller <[email protected]>; [email protected]
> Cc: [email protected]; Madalin Bucur <[email protected]>;
> Jakub Kicinski <[email protected]>; Eric Dumazet <[email protected]>;
> Paolo Abeni <[email protected]>; Camelia Alexandra Groza
> <[email protected]>; Geert Uytterhoeven <[email protected]>; Sean
> Anderson <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Sean Anderson <[email protected]>
> ---
>
> 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 <[email protected]>
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/[email protected]/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/[email protected]/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 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/[email protected]/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
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/[email protected]/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
> -----Original Message-----
> From: Sean Anderson <[email protected]>
> Sent: 19 October 2022 00:47
> To: Andrew Lunn <[email protected]>; Andrew Davis <[email protected]>
> Cc: David S . Miller <[email protected]>; [email protected];
> [email protected]; Madalin Bucur <[email protected]>;
> Jakub Kicinski <[email protected]>; Eric Dumazet <[email protected]>;
> Paolo Abeni <[email protected]>; Camelia Alexandra Groza
> <[email protected]>; Geert Uytterhoeven <[email protected]>
> 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 <[email protected]> wrote:
> > -----Original Message-----
> > From: Sean Anderson <[email protected]>
> > Sent: 19 October 2022 00:47
> > To: Andrew Lunn <[email protected]>; Andrew Davis <[email protected]>
> > Cc: David S . Miller <[email protected]>; [email protected];
> > [email protected]; Madalin Bucur <[email protected]>;
> > Jakub Kicinski <[email protected]>; Eric Dumazet <[email protected]>;
> > Paolo Abeni <[email protected]>; Camelia Alexandra Groza
> > <[email protected]>; Geert Uytterhoeven <[email protected]>
> > 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 -- [email protected]
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 <[email protected]> wrote:
>>> -----Original Message-----
>>> From: Sean Anderson <[email protected]>
>>> Sent: 19 October 2022 00:47
>>> To: Andrew Lunn <[email protected]>; Andrew Davis <[email protected]>
>>> Cc: David S . Miller <[email protected]>; [email protected];
>>> [email protected]; Madalin Bucur <[email protected]>;
>>> Jakub Kicinski <[email protected]>; Eric Dumazet <[email protected]>;
>>> Paolo Abeni <[email protected]>; Camelia Alexandra Groza
>>> <[email protected]>; Geert Uytterhoeven <[email protected]>
>>> 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 -- [email protected]
>
> 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