From: Andrew Davis <afd@ti.com>
To: Sean Anderson <sean.anderson@seco.com>, Andrew Lunn <andrew@lunn.ch>
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 Groza <camelia.groza@nxp.com>,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH net] net: fman: Use physical address for userspace interfaces
Date: Tue, 18 Oct 2022 13:33:55 -0500 [thread overview]
Message-ID: <97aae18e-a96c-a81b-74b7-03e32131a58f@ti.com> (raw)
In-Reply-To: <c409789a-68cb-7aba-af31-31488b16f918@seco.com>
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
next prev parent reply other threads:[~2022-10-18 18:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-17 16:28 Sean Anderson
2022-10-18 6:45 ` Madalin Bucur
2022-10-18 17:22 ` Andrew Lunn
2022-10-18 17:37 ` Sean Anderson
2022-10-18 18:33 ` Andrew Davis [this message]
2022-10-18 21:39 ` Andrew Lunn
2022-10-18 21:47 ` Sean Anderson
2022-10-19 5:20 ` Madalin Bucur
2022-10-19 6:46 ` Geert Uytterhoeven
2022-10-19 12:49 ` Andrew Lunn
2022-10-19 15:04 ` Sean Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=97aae18e-a96c-a81b-74b7-03e32131a58f@ti.com \
--to=afd@ti.com \
--cc=andrew@lunn.ch \
--cc=camelia.groza@nxp.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=geert@linux-m68k.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=madalin.bucur@nxp.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sean.anderson@seco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®