* Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel
From: Jason A. Donenfeld @ 2018-08-13 17:55 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-kernel, netdev, davem, linux-crypto
In-Reply-To: <1534181830.7872.10.camel@HansenPartnership.com>
> but it's very hard for a flow classifier because you have to
The construction and identifier strings might not obviously help with
the extremely narrow idea you've brought up, but it is very important
for safely introducing additional versions. Namely, it prevents
against cross-protocol key reuse attacks and type confusion bugs. So
don't be too quick to dismiss the importance of these for
accomplishing what we're after.
> so lets pick one of the above and try it out.
We have, multiple times, and it's absolutely trivial to do and works
well. The exact thing you're concerned about has already been
researched and worked with on live systems quite a bit over the last 3
years, and it works in a pretty straight forward way. I'm not sure
there's much more to add here: the thing you want is already there and
has been tested extensively. At this point the "pick one and let's try
it out!" is an old story, and the focus now is on making sure the code
quality and netdev api usage is correct for merging
^ permalink raw reply
* pull request: bluetooth-next 2018-08-13
From: Johan Hedberg @ 2018-08-13 15:00 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 940 bytes --]
Hi Dave,
There was one pretty bad bug that slipped into the MediaTek HCI driver
in the last bluetooth-next pull request. Would it be possible to get
this one-liner fix pulled to net-next before you make your first 4.19
pull request for Linus? Thanks.
Johan
---
The following changes since commit a487711aac3b720b4a3a63d737604f47cd8dc36c:
Merge branch 'r8169-smaller-improvements' (2018-08-10 14:32:35 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream
for you to fetch changes up to 330ad75f6a79d46f11f7bf8937852ebb4673b1d5:
Bluetooth: mediatek: pass correct size to h4_recv_buf() (2018-08-13 15:59:39 +0200)
----------------------------------------------------------------
Dan Carpenter (1):
Bluetooth: mediatek: pass correct size to h4_recv_buf()
drivers/bluetooth/btmtkuart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel
From: James Bottomley @ 2018-08-13 17:37 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: linux-kernel, netdev, davem, linux-crypto
In-Reply-To: <CAHmME9raa81A_hH_Zykp2r8zOk0ySroFEsk+8384vnVOCuSa=g@mail.gmail.com>
On Mon, 2018-08-13 at 10:02 -0700, Jason A. Donenfeld wrote:
> > Could we please build planning for this crypto failure day into
> > wireguard now rather than have to do it later? It doesn't need to
> > be full cipher agility, it just needs to be the ability to handle
> > multiple protocol versions ... two should do it because that gives
> > a template to follow (and test version to try to find bugs in the
> > implementation). It looks like the protocol could simply be updated
> > to put the version into one (or more) of the three reserved bytes
> > in the handshake headers, so perhaps doing this before they get
> > used for something else would be a good first step?
> >
> > James
> >
> >
>
> Indeed the answer is in fact along the lines of what you've suggested
> in your question: the protocol is very strictly versioned. This means
> that while there intentionally isn't negotiation of ciphers --
> something historically very bug-prone -- there is ample room for
> updating the protocol. This is enabled via 4 aspects of the protocol:
>
> - An explicit "identifier" string is hashed in as part of the first
> step of cryptographic operations, containing a "v1" as well as the
> protocol designer's email.
> - An explicit "construction" string is hashed in as part of the first
> step of cryptographic operations, containing the Noise handshake
> pattern and a list of the cryptographic primitives used.
Any hash involving other parameters allows you to check for a version
mismatch, but it's very hard for a flow classifier because you have to
do the hash at the point you classify. If we're running concurrent
versions we need an easy way to separate them.
> - A type field at the beginning of each message. Newer message types
> (corresponding with newer versions) can easily be introduced via this
> field, and they can even coexist with older ones need be.
> - Three unused reserved fields ready to be utilised in the event
> they're needed.
Either of these will work for easy classification.
> In other words, there's ample room for such contingency measures
> within the protocol.
I have a preference for explicit versioning, having dealt with some
protocol issues before. However, I'm much less concerned with *how*
it's done than that it *be* done in the kernel patch so we can test out
rolling the version number to change the algorithms in a backward
compatible way, so lets pick one of the above and try it out.
Regards,
James
^ permalink raw reply
* Re: [PATCH bpf-next 1/4] bpf: Introduce bpf_skb_ancestor_cgroup_id helper
From: Tejun Heo @ 2018-08-13 14:46 UTC (permalink / raw)
To: Andrey Ignatov; +Cc: netdev, ast, daniel, guro, kernel-team
In-Reply-To: <b7abb909209e02651d873d90fe8825b432c73f0e.1533965421.git.rdna@fb.com>
Hello, Andrey.
On Fri, Aug 10, 2018 at 10:35:23PM -0700, Andrey Ignatov wrote:
> +static inline struct cgroup *cgroup_ancestor(struct cgroup *cgrp,
> + int ancestor_level)
> +{
> + struct cgroup *ptr;
> +
> + if (cgrp->level < ancestor_level)
> + return NULL;
> +
> + for (ptr = cgrp;
> + ptr && ptr->level > ancestor_level;
> + ptr = cgroup_parent(ptr))
> + ;
> +
> + if (ptr && ptr->level == ancestor_level)
> + return ptr;
> +
> + return NULL;
> +}
I don't have any objections functionanlity-wise but can we do sth like
the following instead?
static inline struct cgroup *cgroup_ancestor(struct cgroup *cgrp,
int ancestor_level)
{
if (cgrp->level < ancestor_level)
return NULL;
while (cgrp->level > ancestor_level)
cgrp = cgroup_parent(cgrp);
return cgrp;
}
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v2 iproute2-next] sch_cake: Make gso-splitting configurable
From: David Ahern @ 2018-08-13 14:45 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: netdev, Dave Taht
In-Reply-To: <20180813113617.13073-1-toke@toke.dk>
On 8/13/18 5:36 AM, Toke Høiland-Jørgensen wrote:
> This patch makes sch_cake's gso/gro splitting configurable
> from userspace.
>
> To disable breaking apart superpackets in sch_cake:
>
> tc qdisc replace dev whatever root cake no-split-gso
>
> to enable:
>
> tc qdisc replace dev whatever root cake split-gso
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
> Signed-off-by: Dave Taht <dave.taht@gmail.com>
> ---
applied to iproute2-next. Thanks
I think you also need to display it if the attribute is returned.
^ permalink raw reply
* Re: [PATCH 2/2] net: socket: Fix potential spectre v1 gadget in sock_is_registered
From: Josh Poimboeuf @ 2018-08-13 17:16 UTC (permalink / raw)
To: Jeremy Cline; +Cc: David S . Miller, netdev, linux-kernel, stable
In-Reply-To: <914d34af-ba80-93b9-6f17-413eef8bf210@redhat.com>
On Sun, Jul 29, 2018 at 11:59:36AM -0400, Jeremy Cline wrote:
> On 07/29/2018 09:59 AM, Josh Poimboeuf wrote:
> > On Fri, Jul 27, 2018 at 10:43:02PM +0000, Jeremy Cline wrote:
> >> 'family' can be a user-controlled value, so sanitize it after the bounds
> >> check to avoid speculative out-of-bounds access.
> >>
> >> Cc: Josh Poimboeuf <jpoimboe@redhat.com>
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Jeremy Cline <jcline@redhat.com>
> >> ---
> >> net/socket.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/net/socket.c b/net/socket.c
> >> index f15d5cbb3ba4..608e29ae6baf 100644
> >> --- a/net/socket.c
> >> +++ b/net/socket.c
> >> @@ -2672,7 +2672,8 @@ EXPORT_SYMBOL(sock_unregister);
> >>
> >> bool sock_is_registered(int family)
> >> {
> >> - return family < NPROTO && rcu_access_pointer(net_families[family]);
> >> + return family < NPROTO &&
> >> + rcu_access_pointer(net_families[array_index_nospec(family, NPROTO)]);
> >> }
> >>
> >> static int __init sock_init(void)
> >
> > This is another one where I think it would be better to do the nospec
> > clamp higher up the call chain. The untrusted 'family' value comes from
> > __sock_diag_cmd():
> >
> > __sock_diag_cmd
> > sock_load_diag_module
> > sock_is_registered
> >
> > That function has a bounds check, and also uses the value in some other
> > array accesses:
> >
> > if (req->sdiag_family >= AF_MAX)
> > return -EINVAL;
> >
> > if (sock_diag_handlers[req->sdiag_family] == NULL)
> > sock_load_diag_module(req->sdiag_family, 0);
> >
> > mutex_lock(&sock_diag_table_mutex);
> > hndl = sock_diag_handlers[req->sdiag_family];
> > ...
> >
> > So I think clamping 'req->sdiag_family' right after the bounds check
> > would be the way to go.
> >
>
> Indeed, the clamp there would cover this clamp. I had a scheme that I
> quickly fix all the gadgets in functions with local comparisons, but
> clearly that's going to result in call chains with multiple clamps.
>
> I can fix this in a follow-up with a clamp here, or respin this patch
> set, whatever is easier for David.
Hi Jeremy,
Just checking up on this... since this patch was merged, will you be
doing a followup patch?
--
Josh
^ permalink raw reply
* Re: [PATCH] mt76: Enable NL80211_EXT_FEATURE_CQM_RSSI_LIST
From: Kristian Evensen @ 2018-08-13 14:25 UTC (permalink / raw)
To: lorenzo.bianconi
Cc: arend.vanspriel, kvalo, linux-wireless, Network Development
In-Reply-To: <CAJ0CqmVZNAnHwnU4YqRRv7R8DyHi2MiFJr1bvQDPVszUU5Ez3g@mail.gmail.com>
Hi Lorenzo,
On Mon, Aug 13, 2018 at 12:55 PM Lorenzo Bianconi
<lorenzo.bianconi@redhat.com> wrote:
> According to my understanding (please correct me if I am wrong)
> BSS_CHANGED_CQM is only needed if CQM_RSSI is handled
> by the driver/fw, while if it is not set mac80211 will take care of that
> in ieee80211_handle_beacon_sig routine.
> I am AFK at the moment, I will test that patch when I am back from vacations.
That matches my understanding as well (base on for example the message
for commit ae44b502669d0cd1f167cdb48994292aa20fd3dd).
Great that you are willing to test the patch with one of the mt76
USB-dongles. Unless anyone objects, I will postpone sending a v2 until
you report back with your findings :)
BR,
Kristian
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2018-08-12
From: David Miller @ 2018-08-13 17:06 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87wosvxwmc.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Sun, 12 Aug 2018 21:34:03 +0300
> one more request to net-next for 4.19. I hope I'm not too late with
> this. These have been in linux-next since Friday so I'm hoping there are
> no surprises. Please let me know if you have any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel
From: Jason A. Donenfeld @ 2018-08-13 17:02 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-kernel, netdev, davem, linux-crypto
In-Reply-To: <1534174811.7872.3.camel@HansenPartnership.com>
Hi James,
On 8/13/18, James Bottomley <James.Bottomley@hansenpartnership.com> wrote:
>> Ample information, including documentation, installation
>> instructions,
>> and project details, is available at:
>>
>> * https://www.wireguard.com/
>> * https://www.wireguard.com/papers/wireguard.pdf
>
> In your paper you say this:
>
>> Finally, WireGuard is cryptographically opinionated. It intentionally
>> lacks cipher and protocol agility. If
>> holes are found in the underlying primitives, all endpoints will be
>> required to update.
>
> The only thing that's certain (beyond death and taxes) is that your
> crypto choice will one day need updating; either in response to an
> urgent CVE because an algorithm is compromised or in response to a less
> urgent one because it is deprecated. Assuming wireguard is reasonably
> successful we'll have a large ecosystem dependent on it. On this day,
> we're going to have the choice of either breaking the entire ecosystem
> by rolling out a change that can't connect to lower protocol versions
> or trying to wedge version agility into wireguard in a hurry. The
> former is too awful to contemplate because of the almost universal
> ecosystem breakage it would cause and the latter is going to lead to
> additional bugs because people in a hurry aren't as careful as they
> should be.
>
> Could we please build planning for this crypto failure day into
> wireguard now rather than have to do it later? It doesn't need to be
> full cipher agility, it just needs to be the ability to handle multiple
> protocol versions ... two should do it because that gives a template to
> follow (and test version to try to find bugs in the implementation).
> It looks like the protocol could simply be updated to put the version
> into one (or more) of the three reserved bytes in the handshake
> headers, so perhaps doing this before they get used for something else
> would be a good first step?
>
> James
>
>
Indeed the answer is in fact along the lines of what you've suggested
in your question: the protocol is very strictly versioned. This means
that while there intentionally isn't negotiation of ciphers --
something historically very bug-prone -- there is ample room for
updating the protocol. This is enabled via 4 aspects of the protocol:
- An explicit "identifier" string is hashed in as part of the first
step of cryptographic operations, containing a "v1" as well as the
protocol designer's email.
- An explicit "construction" string is hashed in as part of the first
step of cryptographic operations, containing the Noise handshake
pattern and a list of the cryptographic primitives used.
- A type field at the beginning of each message. Newer message types
(corresponding with newer versions) can easily be introduced via this
field, and they can even coexist with older ones need be.
- Three unused reserved fields ready to be utilised in the event they're needed.
In other words, there's ample room for such contingency measures
within the protocol.
Jason
^ permalink raw reply
* Re: [PATCH v2 net-next] liquidio: remove set but not used variable 'is25G'
From: David Miller @ 2018-08-13 16:48 UTC (permalink / raw)
To: yuehaibing
Cc: derek.chickles, satananda.burla, felix.manlunas, raghu.vatsavayi,
linux-kernel, netdev
In-Reply-To: <20180813092936.5200-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 13 Aug 2018 17:29:36 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c: In function 'lio_set_link_ksettings':
> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:392:6: warning:
> variable 'is25G' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> v2: remove unnecessary braces as Shahed suggested
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] cxgb4: remove set but not used variable 'spd'
From: David Miller @ 2018-08-13 16:48 UTC (permalink / raw)
To: yuehaibing; +Cc: ganeshgr, linux-kernel, netdev
In-Reply-To: <20180813064851.912-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 13 Aug 2018 14:48:51 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function 'print_port_info':
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:5147:14: warning:
> variable 'spd' set but not used [-Wunused-but-set-variable]
>
> variable 'spd' is set but not used since
> commit 547fd27241a8 ("cxgb4: Warn if device doesn't have enough PCI bandwidth")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: stmmac: Add SMC support for EMAC System Manager register
From: David Miller @ 2018-08-13 16:48 UTC (permalink / raw)
To: joyce.ooi
Cc: peppe.cavallaro, alexandre.torgue, joabreu, netdev, linux-kernel,
hean.loong.ong, yves.vandervennet
In-Reply-To: <1534142494-11541-1-git-send-email-joyce.ooi@intel.com>
From: "Ooi, Joyce" <joyce.ooi@intel.com>
Date: Sun, 12 Aug 2018 23:41:34 -0700
> As there is restriction to access to EMAC System Manager registers in
> the kernel for Intel Stratix10, the use of SMC calls are required and
> added in dwmac-socfpga driver.
>
> Signed-off-by: Ooi, Joyce <joyce.ooi@intel.com>
> ---
> This patch is dependent on https://lkml.org/lkml/2018/7/26/624
I guess I cannot apply this to my networking tree then.
I would suggest that you make a helper in a header file which dos the
special SMC EMAC accesses, or alternatively the regular regmap access,
based upon the CPP ifdef.
That way you won't have to put all of those CPP tests in the foo.c
code.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: remove duplicated include from virtio_net.c
From: David Miller @ 2018-08-13 16:46 UTC (permalink / raw)
To: yuehaibing; +Cc: mst, jasowang, linux-kernel, netdev, virtualization
In-Reply-To: <20180813061315.9084-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 13 Aug 2018 14:13:15 +0800
> Remove duplicated include linux/netdevice.h
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] IB/ipoib: Stop using dev_id to expose port numbers
From: Arseny Maslennikov @ 2018-08-13 13:57 UTC (permalink / raw)
To: Yuval Shaia; +Cc: linux-rdma, Doug Ledford, Jason Gunthorpe, netdev
In-Reply-To: <20180813124018.GA6122@lap1>
[-- Attachment #1: Type: text/plain, Size: 2342 bytes --]
On Mon, Aug 13, 2018 at 03:40:20PM +0300, Yuval Shaia wrote:
> On Mon, Aug 13, 2018 at 02:42:23PM +0300, Arseny Maslennikov wrote:
> > Some InfiniBand network devices have multiple ports on the same PCI
> > function. Prior to this the kernel erroneously used the `dev_id' sysfs
> > field of those network interfaces to convey the port number to userspace.
> >
> > `dev_id' is currently reserved for distinguishing stacked ifaces
> > (e.g: VLANs) with the same hardware address as their parent device.
> >
> > Similar fixes to net/mlx4_en and many other drivers, which started
> > exporting this information through `dev_id' before 3.15, were accepted
> > into the kernel 4 years ago.
> > See 76a066f2a2a0268b565459c417b59724b5a3197b, commit message:
> > `net/mlx4_en: Expose port number through sysfs'.
> >
> > I would be OK with this commit not being backported to stable, since
> > it might break admin-supplied udev rules and the likes.
> >
> > Signed-off-by: Arseny Maslennikov <ar@cs.msu.ru>
> > ---
> > drivers/infiniband/ulp/ipoib/ipoib_main.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > index 6eb0594fffec..f64535038147 100644
> > --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> > @@ -2252,7 +2252,6 @@ static struct net_device *ipoib_add_port(const char *format,
> > }
> >
> > SET_NETDEV_DEV(priv->dev, hca->dev.parent);
> > - priv->dev->dev_id = port - 1;
>
> Correct me if i'm wrong here but besides some changes in commit message
> looks like patch 1/3 is the same as 2/3, isn't it?
>
> Yuval
>
1/3 has an extra line, 2/3 removes a different line.
(a) If you apply both 1/3 and 2/3, the port number can be seen at
/sys/class/net/*/dev_port and not at .../dev_id.
(b) If you apply only 1/3, the port number can be seen at _both_
.../dev_port and .../dev_id (to preserve backward compatibility with
e.g. existing udev rules that rely on "ATTR{dev_id}")
By splitting those up we have both options (a) and (b) available,
so the maintainers are free to decide which one is wiser.
> > priv->dev->dev_port = port - 1;
> >
> > result = ib_query_port(hca, port, &attr);
> > --
> > 2.18.0
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Change the layout of structure trace_event_raw_fib_table_lookup
From: David Miller @ 2018-08-13 16:37 UTC (permalink / raw)
To: zong; +Cc: rostedt, mingo, dsahern, netdev, linux-kernel, zongbox, greentime
In-Reply-To: <1534127212-13186-1-git-send-email-zong@andestech.com>
From: Zong Li <zong@andestech.com>
Date: Mon, 13 Aug 2018 10:26:52 +0800
> There is an unalignment access about the structure
> 'trace_event_raw_fib_table_lookup'.
>
> In include/trace/events/fib.h, there is a memory operation which casting
> the 'src' data member to a pointer, and then store a value to this
> pointer point to.
>
> p32 = (__be32 *) __entry->src;
> *p32 = flp->saddr;
>
> The offset of 'src' in structure trace_event_raw_fib_table_lookup is not
> four bytes alignment. On some architectures, they don't permit the
> unalignment access, it need to pay the price to handle this situation in
> exception handler.
>
> Adjust the layout of structure to avoid this case.
>
> Signed-off-by: Zong Li <zong@andestech.com>
Applied, with Fixes tag from David added.
^ permalink raw reply
* Re: [Query]: DSA Understanding
From: Andrew Lunn @ 2018-08-13 13:38 UTC (permalink / raw)
To: Lad, Prabhakar; +Cc: Florian Fainelli, netdev
In-Reply-To: <CA+V-a8tXStPqWGtJdvC0KzsgsPyGoXY7H8gGfXC+7s0dE9koaQ@mail.gmail.com>
> > I agree, this should be padding packets correctly, can you still
> > instrument cpsw to make sure that what comes to its ndo_start_xmit() is
> > ETH_ZLEN + tag_len or more?
> >
> Yes I can confirm the skb->len is always >= 62 (ETH_ZLEN + 2)
Which switch are you using?
Marvell switches use either 4 or 8 bytes of tag. Broadcom has 4, KSZ
has 1 for packets going to the switch, lan9303 has 4, mtd uses 4, qca
has 2.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 5/9] net: hns3: Fix for vf vlan delete failed problem
From: David Miller @ 2018-08-13 15:56 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil.lnk, netdev, linux-kernel,
linuxarm, linyunsheng
In-Reply-To: <20180812094738.14852-6-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Sun, 12 Aug 2018 10:47:34 +0100
> Fixes: 9dba194574e3 ("{topost} net: hns3: fix for vlan table problem")
This commit ID doesn't exist.
Also, I really don't think the string "{topost}" would be in the commit
header line.
^ permalink raw reply
* Re: [PATCH net-next 1/9] net: hns3: Add support for serdes loopback selftest
From: David Miller @ 2018-08-13 15:54 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil.lnk, netdev, linux-kernel,
linuxarm, linyunsheng
In-Reply-To: <20180812094738.14852-2-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Sun, 12 Aug 2018 10:47:30 +0100
> -#define HNS3_SELF_TEST_TPYE_NUM 1
> +#define HNS3_SELF_TEST_TPYE_NUM 2
Is this supposed to be the number of self test "types"? If so, this CPP
macro should be named "HNS3_SELF_TEST_TYPE_NUM".
> +
> + count ++;
^
Please remove that unnecessary space.
> + } while (++i < HCLGE_SERDES_RETRY_NUM &&
^^
Only need one space there, not two.
^ permalink raw reply
* Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel
From: Willy Tarreau @ 2018-08-13 15:53 UTC (permalink / raw)
To: James Bottomley
Cc: Jason A. Donenfeld, linux-kernel, netdev, davem, linux-crypto
In-Reply-To: <1534174811.7872.3.camel@HansenPartnership.com>
On Mon, Aug 13, 2018 at 08:40:11AM -0700, James Bottomley wrote:
> Could we please build planning for this crypto failure day into
> wireguard now rather than have to do it later? It doesn't need to be
> full cipher agility, it just needs to be the ability to handle multiple
> protocol versions ... two should do it because that gives a template to
> follow (and test version to try to find bugs in the implementation).
It's also what provides a *real* upgrade path to future versions :
before deploying you need something which works, and the only way to
get something working at a large scale is to have early adopters. Those
willing to deploy a beta version will not do it if it requires to lose
all their users and possibly to make rollbacks impossible. At least for
this it's important to support an optionnal new version on top of the
existing one (i.e. prod + beta together).
Cheers,
Willy
^ permalink raw reply
* Re: [PATCH v2] xen-netfront: fix warn message as irq device name has '/'
From: David Miller @ 2018-08-13 15:52 UTC (permalink / raw)
To: xiliang; +Cc: netdev, xen-devel, jgross, boris.ostrovsky, linux-kernel
In-Reply-To: <20180811152137.3627-1-xiliang@redhat.com>
From: Xiao Liang <xiliang@redhat.com>
Date: Sat, 11 Aug 2018 23:21:37 +0800
> There is a call trace generated after commit 2d408c0d4574b01b9ed45e02516888bf925e11a9(
> xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file found
> under /proc/irq/xx/.
>
> This patch only picks up device type and id as its name.
This adds a compile warning:
drivers/net/xen-netfront.c: In function ‘xennet_init_queue’:
drivers/net/xen-netfront.c:1614:2: warning: ignoring return value of ‘kstrtoint’, declared with attribute warn_unused_result [-Wunused-result]
kstrtoint(strrchr(queue->info->xbdev->nodename, '/') + 1, 10, &devid);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCH 0/2] net: nixge: Minor cleanups
From: David Miller @ 2018-08-13 15:49 UTC (permalink / raw)
To: mdf; +Cc: keescook, netdev, linux-kernel, alex.williams
In-Reply-To: <20180811011941.6187-1-mdf@kernel.org>
From: Moritz Fischer <mdf@kernel.org>
Date: Fri, 10 Aug 2018 18:19:39 -0700
> in preparation of my 64-bit support series, here's some
> minor cleanup in preparation that gets rid of unneccesary
> accesses to the descriptor application fields.
>
> I've confirmed that the hardware does not access the fields
> in all our configurations.
Series applied, thank you.
^ permalink raw reply
* Re: [V9fs-developer] [PATCH 2/2] 9p: Add refcount to p9_req_t
From: Dmitry Vyukov @ 2018-08-13 13:04 UTC (permalink / raw)
To: Dominique Martinet
Cc: piaojun, Tomas Bortoli, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov, Dominique Martinet, netdev, LKML, syzkaller,
v9fs-developer, David Miller
In-Reply-To: <20180813014815.GB6777@nautica>
On Mon, Aug 13, 2018 at 3:48 AM, Dominique Martinet
<asmadeus@codewreck.org> wrote:
> piaojun wrote on Mon, Aug 13, 2018:
>> Could you help paste the reason of the crash bug to help others
>> understand more clearly? And I have another question below.
>
> The problem for tcp (but other transports have a similar problem) is
> that with a malicious server like syzkaller they can try to submit
> replies before the request came in.
>
> This leads in the writer thread trying to write a buffer that has
> already been freed, and if memory has been reused could potentially leak
> some information.
>
> Now, with the previous patches this is based on this would be a slab and
> the likeliness of it being sensitive information is rather low (it would
> likely be some other packet being sent twice, or a mix and match of two
> packets that would have been sent anyway), but it would nevertheless be
> a use after free.
>
>
> There is a second advantage to this reference counting, that is now we
> have this system we will be able to implement flush asynchronously.
> This will remove the need for the 'goto again' in p9_client_rpc which
> was making 9p threads unkillable in practice if the server would not
> reply to the flush requests.
Fixing unkillalble task would be nice. Don't know how much they are of
a problem in real life, but fixing them would allow fuzzer to find
other, potentially more critical bugs in 9p. These "task hung" crashes
are quite unpleasant for the fuzzer.
Thanks for all recent 9p work, Tomas!
> Even if the server replies I've always found myself needing to hit ^C
> multiple times to exit a process doing I/Os and I think fixing that
> behaviour will make 9p more comfortable to use.
>
>
>> > diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
>> > index 20f46f13fe83..686e24e355d0 100644
>> > --- a/net/9p/trans_fd.c
>> > +++ b/net/9p/trans_fd.c
>> > @@ -132,6 +132,7 @@ struct p9_conn {
>> > struct list_head req_list;
>> > struct list_head unsent_req_list;
>> > struct p9_req_t *req;
>> > + struct p9_req_t *wreq;
>>
>> Why adding a wreq for write work? And I wonder we should rename req to
>> rreq?
>
> We need to store a pointer to the request for the write thread because
> we need to put the reference to it when we're done writing its content.
>
> Previously, the worker would only store the write buffer there but
> that's not enough to figure what request to dereference.
>
>
> I personally don't think renaming req to rreq would bring much but it
> could be done in another patch if you think that'd be helpful; I think
> it shouldn't be done here at least to make the patch more readable.
>
> --
> Dominique
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2] Add icmp_echo_ignore_all support for ICMPv6
From: David Miller @ 2018-08-13 15:42 UTC (permalink / raw)
To: virgile; +Cc: kuznet, yoshfuji, netdev, linux-kernel
In-Reply-To: <20180810154815.GA18171@_>
From: Virgile Jarry <virgile@acceis.fr>
Date: Fri, 10 Aug 2018 17:48:15 +0200
> Preventing the kernel from responding to ICMP Echo Requests messages
> can be useful in several ways. The sysctl parameter
> 'icmp_echo_ignore_all' can be used to prevent the kernel from
> responding to IPv4 ICMP echo requests. For IPv6 pings, such
> a sysctl kernel parameter did not exist.
>
> Add the ability to prevent the kernel from responding to IPv6
> ICMP echo requests through the use of the following sysctl
> parameter : /proc/sys/net/ipv6/icmp/echo_ignore_all.
> Update the documentation to reflect this change.
>
> Signed-off-by: Virgile Jarry <virgile@acceis.fr>
> ---
> Changes in v2:
> - Added support for sysctl interface (and not just /proc filesystem)
Applied.
^ permalink raw reply
* Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel
From: James Bottomley @ 2018-08-13 15:40 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: linux-kernel, netdev, davem, linux-crypto
In-Reply-To: <20180731191102.2434-1-Jason@zx2c4.com>
> Ample information, including documentation, installation
> instructions,
> and project details, is available at:
>
> * https://www.wireguard.com/
> * https://www.wireguard.com/papers/wireguard.pdf
In your paper you say this:
> Finally, WireGuard is cryptographically opinionated. It intentionally
> lacks cipher and protocol agility. If
> holes are found in the underlying primitives, all endpoints will be
> required to update.
The only thing that's certain (beyond death and taxes) is that your
crypto choice will one day need updating; either in response to an
urgent CVE because an algorithm is compromised or in response to a less
urgent one because it is deprecated. Assuming wireguard is reasonably
successful we'll have a large ecosystem dependent on it. On this day,
we're going to have the choice of either breaking the entire ecosystem
by rolling out a change that can't connect to lower protocol versions
or trying to wedge version agility into wireguard in a hurry. The
former is too awful to contemplate because of the almost universal
ecosystem breakage it would cause and the latter is going to lead to
additional bugs because people in a hurry aren't as careful as they
should be.
Could we please build planning for this crypto failure day into
wireguard now rather than have to do it later? It doesn't need to be
full cipher agility, it just needs to be the ability to handle multiple
protocol versions ... two should do it because that gives a template to
follow (and test version to try to find bugs in the implementation).
It looks like the protocol could simply be updated to put the version
into one (or more) of the three reserved bytes in the handshake
headers, so perhaps doing this before they get used for something else
would be a good first step?
James
^ permalink raw reply
* Re: possible deadlock in flush_work (3)
From: Xin Long @ 2018-08-13 15:39 UTC (permalink / raw)
To: syzbot
Cc: Christian Brauner, davem, David Ahern, Florian Westphal,
Jiri Benc, Kirill Tkhai, LKML, network dev, Nicolas Dichtel,
syzkaller-bugs, Moni Shoua
In-Reply-To: <0000000000009637a6057350529b@google.com>
On Mon, Aug 13, 2018 at 8:35 PM, syzbot
<syzbot+a8371264572a6872b8a3@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: d6dd6431591b Merge branch 'fixes' of git://git.kernel.org/..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14e800aa400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=152cb8ccd35b1f70
> dashboard link: https://syzkaller.appspot.com/bug?extid=a8371264572a6872b8a3
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a8371264572a6872b8a3@syzkaller.appspotmail.com
>
> 8021q: adding VLAN 0 to HW filter on device bond0
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 4.18.0-rc8+ #185 Not tainted
> ------------------------------------------------------
> syz-executor2/6421 is trying to acquire lock:
> 00000000209b4e4b ((wq_completion)bond_dev->name){+.+.}, at: start_flush_work
> kernel/workqueue.c:2888 [inline]
> 00000000209b4e4b ((wq_completion)bond_dev->name){+.+.}, at:
> flush_work+0x4b8/0x900 kernel/workqueue.c:2917
>
> but task is already holding lock:
> 00000000f0f3d47a (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:77
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (rtnl_mutex){+.+.}:
> __mutex_lock_common kernel/locking/mutex.c:757 [inline]
> __mutex_lock+0x176/0x1820 kernel/locking/mutex.c:894
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:909
> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:77
> bond_netdev_notify drivers/net/bonding/bond_main.c:1310 [inline]
> bond_netdev_notify_work+0x44/0xd0
> drivers/net/bonding/bond_main.c:1320
> process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
> worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
> kthread+0x345/0x410 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
>
> -> #1 ((work_completion)(&(&nnw->work)->work)){+.+.}:
> process_one_work+0xc0b/0x1ba0 kernel/workqueue.c:2129
> worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
> kthread+0x345/0x410 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
>
> -> #0 ((wq_completion)bond_dev->name){+.+.}:
> lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
> start_flush_work kernel/workqueue.c:2889 [inline]
> flush_work+0x4dd/0x900 kernel/workqueue.c:2917
> __cancel_work_timer+0x4bd/0x830 kernel/workqueue.c:2989
> cancel_delayed_work_sync+0x1a/0x20 kernel/workqueue.c:3121
> bond_work_cancel_all drivers/net/bonding/bond_main.c:3318 [inline]
> bond_close+0x1b/0x130 drivers/net/bonding/bond_main.c:3381
> __dev_close_many+0x21e/0x380 net/core/dev.c:1476
> __dev_close net/core/dev.c:1488 [inline]
> __dev_change_flags+0x38d/0x9c0 net/core/dev.c:6989
> dev_change_flags+0x89/0x150 net/core/dev.c:7060
> dev_ifsioc+0x84f/0xb30 net/core/dev_ioctl.c:237
> dev_ioctl+0x1b5/0xcc0 net/core/dev_ioctl.c:493
> sock_do_ioctl+0x1d3/0x3e0 net/socket.c:993
> sock_ioctl+0x30d/0x680 net/socket.c:1094
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:500 [inline]
> do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:684
> ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
> __do_sys_ioctl fs/ioctl.c:708 [inline]
> __se_sys_ioctl fs/ioctl.c:706 [inline]
> __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> other info that might help us debug this:
>
> Chain exists of:
> (wq_completion)bond_dev->name --> (work_completion)(&(&nnw->work)->work)
> --> rtnl_mutex
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(rtnl_mutex);
> lock((work_completion)(&(&nnw->work)->work));
> lock(rtnl_mutex);
> lock((wq_completion)bond_dev->name);
nnw->work is queuing up into bond->wq, so it seems bond_netdev_notify()
should have used rtnl_trylock() instead of rtnl_lock(), as do other
delayed_work handlers in bond->wq.
>
> *** DEADLOCK ***
>
> 1 lock held by syz-executor2/6421:
> #0: 00000000f0f3d47a (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:77
>
> stack backtrace:
> CPU: 0 PID: 6421 Comm: syz-executor2 Not tainted 4.18.0-rc8+ #185
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_circular_bug.isra.36.cold.57+0x1bd/0x27d
> kernel/locking/lockdep.c:1227
> check_prev_add kernel/locking/lockdep.c:1867 [inline]
> check_prevs_add kernel/locking/lockdep.c:1980 [inline]
> validate_chain kernel/locking/lockdep.c:2421 [inline]
> __lock_acquire+0x3449/0x5020 kernel/locking/lockdep.c:3435
> lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
> start_flush_work kernel/workqueue.c:2889 [inline]
> flush_work+0x4dd/0x900 kernel/workqueue.c:2917
> __cancel_work_timer+0x4bd/0x830 kernel/workqueue.c:2989
> cancel_delayed_work_sync+0x1a/0x20 kernel/workqueue.c:3121
> bond_work_cancel_all drivers/net/bonding/bond_main.c:3318 [inline]
> bond_close+0x1b/0x130 drivers/net/bonding/bond_main.c:3381
> __dev_close_many+0x21e/0x380 net/core/dev.c:1476
> __dev_close net/core/dev.c:1488 [inline]
> __dev_change_flags+0x38d/0x9c0 net/core/dev.c:6989
> dev_change_flags+0x89/0x150 net/core/dev.c:7060
> dev_ifsioc+0x84f/0xb30 net/core/dev_ioctl.c:237
> dev_ioctl+0x1b5/0xcc0 net/core/dev_ioctl.c:493
> sock_do_ioctl+0x1d3/0x3e0 net/socket.c:993
> kernel msg: ebtables bug: please report to author: Wrong nr of counters
> sock_ioctl+0x30d/0x680 net/socket.c:1094
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:500 [inline]
> do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:684
> ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
> __do_sys_ioctl fs/ioctl.c:708 [inline]
> __se_sys_ioctl fs/ioctl.c:706 [inline]
> __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x457089
> Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
> 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fee7b2ccc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007fee7b2cd6d4 RCX: 0000000000457089
> RDX: 0000000020000140 RSI: 0000000000008914 RDI: 0000000000000004
> RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
> R13: 00000000004d19e0 R14: 00000000004c7454 R15: 0000000000000000
> 8021q: adding VLAN 0 to HW filter on device bond0
> (unnamed net_device) (uninitialized): option miimon: invalid value
> (18446744073709551615)
> (unnamed net_device) (uninitialized): option miimon: allowed values 0 -
> 2147483647
> (unnamed net_device) (uninitialized): option miimon: invalid value
> (18446744073709551615)
> (unnamed net_device) (uninitialized): option miimon: allowed values 0 -
> 2147483647
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> device bond0 left promiscuous mode
> IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
> 8021q: adding VLAN 0 to HW filter on device bond0
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox