* [PATCH v2] macvlan: validate flags
@ 2013-08-01 16:09 Michael S. Tsirkin
2013-08-01 17:24 ` John Fastabend
0 siblings, 1 reply; 6+ messages in thread
From: Michael S. Tsirkin @ 2013-08-01 16:09 UTC (permalink / raw)
To: linux-kernel; +Cc: David S. Miller, John Fastabend, Patrick McHardy, netdev
commit df8ef8f3aaa6692970a436204c4429210addb23a
macvlan: add FDB bridge ops and macvlan flags
added a flags field to macvlan, which can be
controlled from userspace.
The idea is to make the interface future-proof
so we can add flags and not new fields.
However, flags value isn't validated, as a result,
userspace can't detect which flags are supported.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
Changes from v1:
tweaked commit message
no code changes
Please consider this patch for -stable.
The idea is by the time we add more flags,
everyone has updated to a kernel that
detects errors, so userspace will be able
to detect supported flags cleanly.
drivers/net/macvlan.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 18373b6..8445a94 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -736,6 +736,10 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
return -EADDRNOTAVAIL;
}
+ if (data && data[IFLA_MACVLAN_FLAGS] &&
+ nla_get_u16(data[IFLA_MACVLAN_FLAGS]) & ~MACVLAN_FLAG_NOPROMISC)
+ return -EINVAL;
+
if (data && data[IFLA_MACVLAN_MODE]) {
switch (nla_get_u32(data[IFLA_MACVLAN_MODE])) {
case MACVLAN_MODE_PRIVATE:
@@ -809,6 +813,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
if (data && data[IFLA_MACVLAN_FLAGS])
vlan->flags = nla_get_u16(data[IFLA_MACVLAN_FLAGS]);
+ if (vlan->flags & ~MACVLAN_FLAG_NOPROMISC)
+ return -EINVAL;
+
if (vlan->mode == MACVLAN_MODE_PASSTHRU) {
if (port->count)
return -EINVAL;
--
MST
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] macvlan: validate flags
2013-08-01 16:09 [PATCH v2] macvlan: validate flags Michael S. Tsirkin
@ 2013-08-01 17:24 ` John Fastabend
2013-08-01 19:19 ` Michael S. Tsirkin
0 siblings, 1 reply; 6+ messages in thread
From: John Fastabend @ 2013-08-01 17:24 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, David S. Miller, Patrick McHardy, netdev
On 8/1/2013 9:09 AM, Michael S. Tsirkin wrote:
> commit df8ef8f3aaa6692970a436204c4429210addb23a
> macvlan: add FDB bridge ops and macvlan flags
> added a flags field to macvlan, which can be
> controlled from userspace.
> The idea is to make the interface future-proof
> so we can add flags and not new fields.
>
> However, flags value isn't validated, as a result,
> userspace can't detect which flags are supported.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: John Fastabend <john.r.fastabend@intel.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> Changes from v1:
> tweaked commit message
> no code changes
>
> Please consider this patch for -stable.
>
> The idea is by the time we add more flags,
> everyone has updated to a kernel that
> detects errors, so userspace will be able
> to detect supported flags cleanly.
>
Agreed and because we haven't added more flags yet this shouldn't
break uapi. Thanks for catching this.
>
> drivers/net/macvlan.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
By the same logic should we also add the check to macvlan_changelink()?
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index 18373b6..8445a94 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -736,6 +736,10 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
> return -EADDRNOTAVAIL;
> }
>
> + if (data && data[IFLA_MACVLAN_FLAGS] &&
> + nla_get_u16(data[IFLA_MACVLAN_FLAGS]) & ~MACVLAN_FLAG_NOPROMISC)
> + return -EINVAL;
> +
> if (data && data[IFLA_MACVLAN_MODE]) {
> switch (nla_get_u32(data[IFLA_MACVLAN_MODE])) {
> case MACVLAN_MODE_PRIVATE:
> @@ -809,6 +813,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
> if (data && data[IFLA_MACVLAN_FLAGS])
> vlan->flags = nla_get_u16(data[IFLA_MACVLAN_FLAGS]);
>
> + if (vlan->flags & ~MACVLAN_FLAG_NOPROMISC)
> + return -EINVAL;
> +
Is there really a case where newlink is called without first calling
validate? I don't think there is so the snippet here in newlink could
be dropped.
Thanks,
John
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] macvlan: validate flags
2013-08-01 17:24 ` John Fastabend
@ 2013-08-01 19:19 ` Michael S. Tsirkin
2013-08-01 19:34 ` John Fastabend
2013-08-01 19:34 ` John Fastabend
0 siblings, 2 replies; 6+ messages in thread
From: Michael S. Tsirkin @ 2013-08-01 19:19 UTC (permalink / raw)
To: John Fastabend; +Cc: linux-kernel, David S. Miller, Patrick McHardy, netdev
On Thu, Aug 01, 2013 at 10:24:19AM -0700, John Fastabend wrote:
> On 8/1/2013 9:09 AM, Michael S. Tsirkin wrote:
> >commit df8ef8f3aaa6692970a436204c4429210addb23a
> > macvlan: add FDB bridge ops and macvlan flags
> >added a flags field to macvlan, which can be
> >controlled from userspace.
> >The idea is to make the interface future-proof
> >so we can add flags and not new fields.
> >
> >However, flags value isn't validated, as a result,
> >userspace can't detect which flags are supported.
> >
> >Cc: "David S. Miller" <davem@davemloft.net>
> >Cc: John Fastabend <john.r.fastabend@intel.com>
> >Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >---
> >
> >Changes from v1:
> > tweaked commit message
> > no code changes
> >
> >Please consider this patch for -stable.
> >
> >The idea is by the time we add more flags,
> >everyone has updated to a kernel that
> >detects errors, so userspace will be able
> >to detect supported flags cleanly.
> >
>
> Agreed and because we haven't added more flags yet this shouldn't
> break uapi. Thanks for catching this.
>
> >
> > drivers/net/macvlan.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
>
> By the same logic should we also add the check to macvlan_changelink()?
I'm not sure what do you mean "By the same logic" -
macvlan_changelink is static unlike macvlan_common_newlink
which is exported to modules.
So why isn't macvlan_validate sufficient for macvlan_changelink?
> >diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> >index 18373b6..8445a94 100644
> >--- a/drivers/net/macvlan.c
> >+++ b/drivers/net/macvlan.c
> >@@ -736,6 +736,10 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
> > return -EADDRNOTAVAIL;
> > }
> >
> >+ if (data && data[IFLA_MACVLAN_FLAGS] &&
> >+ nla_get_u16(data[IFLA_MACVLAN_FLAGS]) & ~MACVLAN_FLAG_NOPROMISC)
> >+ return -EINVAL;
> >+
> > if (data && data[IFLA_MACVLAN_MODE]) {
> > switch (nla_get_u32(data[IFLA_MACVLAN_MODE])) {
> > case MACVLAN_MODE_PRIVATE:
> >@@ -809,6 +813,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
> > if (data && data[IFLA_MACVLAN_FLAGS])
> > vlan->flags = nla_get_u16(data[IFLA_MACVLAN_FLAGS]);
> >
> >+ if (vlan->flags & ~MACVLAN_FLAG_NOPROMISC)
> >+ return -EINVAL;
> >+
>
> Is there really a case where newlink is called without first calling
> validate? I don't think there is so the snippet here in newlink could
> be dropped.
>
> Thanks,
> John
It seems so - macvtap_newlink calls macvlan_common_newlink.
macvtap does not seem to have .validate.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] macvlan: validate flags
2013-08-01 19:19 ` Michael S. Tsirkin
@ 2013-08-01 19:34 ` John Fastabend
2013-08-01 19:43 ` Michael S. Tsirkin
2013-08-01 19:34 ` John Fastabend
1 sibling, 1 reply; 6+ messages in thread
From: John Fastabend @ 2013-08-01 19:34 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, David S. Miller, Patrick McHardy, netdev
On 8/1/2013 12:19 PM, Michael S. Tsirkin wrote:
> On Thu, Aug 01, 2013 at 10:24:19AM -0700, John Fastabend wrote:
>> On 8/1/2013 9:09 AM, Michael S. Tsirkin wrote:
>>> commit df8ef8f3aaa6692970a436204c4429210addb23a
>>> macvlan: add FDB bridge ops and macvlan flags
>>> added a flags field to macvlan, which can be
>>> controlled from userspace.
>>> The idea is to make the interface future-proof
>>> so we can add flags and not new fields.
>>>
>>> However, flags value isn't validated, as a result,
>>> userspace can't detect which flags are supported.
>>>
>>> Cc: "David S. Miller" <davem@davemloft.net>
>>> Cc: John Fastabend <john.r.fastabend@intel.com>
>>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>> ---
>>>
>>> Changes from v1:
>>> tweaked commit message
>>> no code changes
>>>
>>> Please consider this patch for -stable.
>>>
>>> The idea is by the time we add more flags,
>>> everyone has updated to a kernel that
>>> detects errors, so userspace will be able
>>> to detect supported flags cleanly.
>>>
>>
>> Agreed and because we haven't added more flags yet this shouldn't
>> break uapi. Thanks for catching this.
>>
>>>
>>> drivers/net/macvlan.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>
>> By the same logic should we also add the check to macvlan_changelink()?
>
> I'm not sure what do you mean "By the same logic" -
> macvlan_changelink is static unlike macvlan_common_newlink
> which is exported to modules.
"By the same logic" I only meant to allow userspace to cleanly detect
supported flags even in the changelink case.
> So why isn't macvlan_validate sufficient for macvlan_changelink?
It is you are correct.
>
>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>> index 18373b6..8445a94 100644
>>> --- a/drivers/net/macvlan.c
>>> +++ b/drivers/net/macvlan.c
>>> @@ -736,6 +736,10 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
>>> return -EADDRNOTAVAIL;
>>> }
>>>
>>> + if (data && data[IFLA_MACVLAN_FLAGS] &&
>>> + nla_get_u16(data[IFLA_MACVLAN_FLAGS]) & ~MACVLAN_FLAG_NOPROMISC)
>>> + return -EINVAL;
>>> +
>>> if (data && data[IFLA_MACVLAN_MODE]) {
>>> switch (nla_get_u32(data[IFLA_MACVLAN_MODE])) {
>>> case MACVLAN_MODE_PRIVATE:
>>> @@ -809,6 +813,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
>>> if (data && data[IFLA_MACVLAN_FLAGS])
>>> vlan->flags = nla_get_u16(data[IFLA_MACVLAN_FLAGS]);
>>>
>>> + if (vlan->flags & ~MACVLAN_FLAG_NOPROMISC)
>>> + return -EINVAL;
>>> +
>>
>> Is there really a case where newlink is called without first calling
>> validate? I don't think there is so the snippet here in newlink could
>> be dropped.
>>
>> Thanks,
>> John
>
> It seems so - macvtap_newlink calls macvlan_common_newlink.
> macvtap does not seem to have .validate.
>
but it calls macvlan_link_register() from macvtap_init which sets
up the validate ops,
int macvlan_link_register(struct rtnl_link_ops *ops)
{
/* common fields */
ops->priv_size = sizeof(struct macvlan_dev);
ops->validate = macvlan_validate
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] macvlan: validate flags
2013-08-01 19:19 ` Michael S. Tsirkin
2013-08-01 19:34 ` John Fastabend
@ 2013-08-01 19:34 ` John Fastabend
1 sibling, 0 replies; 6+ messages in thread
From: John Fastabend @ 2013-08-01 19:34 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, David S. Miller, Patrick McHardy, netdev
On 8/1/2013 12:19 PM, Michael S. Tsirkin wrote:
> On Thu, Aug 01, 2013 at 10:24:19AM -0700, John Fastabend wrote:
>> On 8/1/2013 9:09 AM, Michael S. Tsirkin wrote:
>>> commit df8ef8f3aaa6692970a436204c4429210addb23a
>>> macvlan: add FDB bridge ops and macvlan flags
>>> added a flags field to macvlan, which can be
>>> controlled from userspace.
>>> The idea is to make the interface future-proof
>>> so we can add flags and not new fields.
>>>
>>> However, flags value isn't validated, as a result,
>>> userspace can't detect which flags are supported.
>>>
>>> Cc: "David S. Miller" <davem@davemloft.net>
>>> Cc: John Fastabend <john.r.fastabend@intel.com>
>>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>> ---
>>>
>>> Changes from v1:
>>> tweaked commit message
>>> no code changes
>>>
>>> Please consider this patch for -stable.
>>>
>>> The idea is by the time we add more flags,
>>> everyone has updated to a kernel that
>>> detects errors, so userspace will be able
>>> to detect supported flags cleanly.
>>>
>>
>> Agreed and because we haven't added more flags yet this shouldn't
>> break uapi. Thanks for catching this.
>>
>>>
>>> drivers/net/macvlan.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>
>> By the same logic should we also add the check to macvlan_changelink()?
>
> I'm not sure what do you mean "By the same logic" -
> macvlan_changelink is static unlike macvlan_common_newlink
> which is exported to modules.
"By the same logic" I only meant to allow userspace to cleanly detect
supported flags even in the changelink case.
> So why isn't macvlan_validate sufficient for macvlan_changelink?
It is you are correct.
>
>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>> index 18373b6..8445a94 100644
>>> --- a/drivers/net/macvlan.c
>>> +++ b/drivers/net/macvlan.c
>>> @@ -736,6 +736,10 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
>>> return -EADDRNOTAVAIL;
>>> }
>>>
>>> + if (data && data[IFLA_MACVLAN_FLAGS] &&
>>> + nla_get_u16(data[IFLA_MACVLAN_FLAGS]) & ~MACVLAN_FLAG_NOPROMISC)
>>> + return -EINVAL;
>>> +
>>> if (data && data[IFLA_MACVLAN_MODE]) {
>>> switch (nla_get_u32(data[IFLA_MACVLAN_MODE])) {
>>> case MACVLAN_MODE_PRIVATE:
>>> @@ -809,6 +813,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
>>> if (data && data[IFLA_MACVLAN_FLAGS])
>>> vlan->flags = nla_get_u16(data[IFLA_MACVLAN_FLAGS]);
>>>
>>> + if (vlan->flags & ~MACVLAN_FLAG_NOPROMISC)
>>> + return -EINVAL;
>>> +
>>
>> Is there really a case where newlink is called without first calling
>> validate? I don't think there is so the snippet here in newlink could
>> be dropped.
>>
>> Thanks,
>> John
>
> It seems so - macvtap_newlink calls macvlan_common_newlink.
> macvtap does not seem to have .validate.
>
but it calls macvlan_link_register() from macvtap_init which sets
up the validate ops,
int macvlan_link_register(struct rtnl_link_ops *ops)
{
/* common fields */
ops->priv_size = sizeof(struct macvlan_dev);
ops->validate = macvlan_validate
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] macvlan: validate flags
2013-08-01 19:34 ` John Fastabend
@ 2013-08-01 19:43 ` Michael S. Tsirkin
0 siblings, 0 replies; 6+ messages in thread
From: Michael S. Tsirkin @ 2013-08-01 19:43 UTC (permalink / raw)
To: John Fastabend; +Cc: linux-kernel, David S. Miller, Patrick McHardy, netdev
On Thu, Aug 01, 2013 at 12:34:24PM -0700, John Fastabend wrote:
> On 8/1/2013 12:19 PM, Michael S. Tsirkin wrote:
> >On Thu, Aug 01, 2013 at 10:24:19AM -0700, John Fastabend wrote:
> >>On 8/1/2013 9:09 AM, Michael S. Tsirkin wrote:
> >>>commit df8ef8f3aaa6692970a436204c4429210addb23a
> >>> macvlan: add FDB bridge ops and macvlan flags
> >>>added a flags field to macvlan, which can be
> >>>controlled from userspace.
> >>>The idea is to make the interface future-proof
> >>>so we can add flags and not new fields.
> >>>
> >>>However, flags value isn't validated, as a result,
> >>>userspace can't detect which flags are supported.
> >>>
> >>>Cc: "David S. Miller" <davem@davemloft.net>
> >>>Cc: John Fastabend <john.r.fastabend@intel.com>
> >>>Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >>>---
> >>>
> >>>Changes from v1:
> >>> tweaked commit message
> >>> no code changes
> >>>
> >>>Please consider this patch for -stable.
> >>>
> >>>The idea is by the time we add more flags,
> >>>everyone has updated to a kernel that
> >>>detects errors, so userspace will be able
> >>>to detect supported flags cleanly.
> >>>
> >>
> >>Agreed and because we haven't added more flags yet this shouldn't
> >>break uapi. Thanks for catching this.
> >>
> >>>
> >>> drivers/net/macvlan.c | 7 +++++++
> >>> 1 file changed, 7 insertions(+)
> >>>
> >>
> >>By the same logic should we also add the check to macvlan_changelink()?
> >
> >I'm not sure what do you mean "By the same logic" -
> >macvlan_changelink is static unlike macvlan_common_newlink
> >which is exported to modules.
>
> "By the same logic" I only meant to allow userspace to cleanly detect
> supported flags even in the changelink case.
>
> >So why isn't macvlan_validate sufficient for macvlan_changelink?
>
> It is you are correct.
>
> >
> >>>diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> >>>index 18373b6..8445a94 100644
> >>>--- a/drivers/net/macvlan.c
> >>>+++ b/drivers/net/macvlan.c
> >>>@@ -736,6 +736,10 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
> >>> return -EADDRNOTAVAIL;
> >>> }
> >>>
> >>>+ if (data && data[IFLA_MACVLAN_FLAGS] &&
> >>>+ nla_get_u16(data[IFLA_MACVLAN_FLAGS]) & ~MACVLAN_FLAG_NOPROMISC)
> >>>+ return -EINVAL;
> >>>+
> >>> if (data && data[IFLA_MACVLAN_MODE]) {
> >>> switch (nla_get_u32(data[IFLA_MACVLAN_MODE])) {
> >>> case MACVLAN_MODE_PRIVATE:
> >>>@@ -809,6 +813,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
> >>> if (data && data[IFLA_MACVLAN_FLAGS])
> >>> vlan->flags = nla_get_u16(data[IFLA_MACVLAN_FLAGS]);
> >>>
> >>>+ if (vlan->flags & ~MACVLAN_FLAG_NOPROMISC)
> >>>+ return -EINVAL;
> >>>+
> >>
> >>Is there really a case where newlink is called without first calling
> >>validate? I don't think there is so the snippet here in newlink could
> >>be dropped.
> >>
> >>Thanks,
> >>John
> >
> >It seems so - macvtap_newlink calls macvlan_common_newlink.
> >macvtap does not seem to have .validate.
> >
>
> but it calls macvlan_link_register() from macvtap_init which sets
> up the validate ops,
>
> int macvlan_link_register(struct rtnl_link_ops *ops)
> {
> /* common fields */
> ops->priv_size = sizeof(struct macvlan_dev);
> ops->validate = macvlan_validate
I see. I'll drop this second chunk in the patch,
thanks for catching this.
--
MST
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-08-01 19:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-01 16:09 [PATCH v2] macvlan: validate flags Michael S. Tsirkin
2013-08-01 17:24 ` John Fastabend
2013-08-01 19:19 ` Michael S. Tsirkin
2013-08-01 19:34 ` John Fastabend
2013-08-01 19:43 ` Michael S. Tsirkin
2013-08-01 19:34 ` John Fastabend
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).