* Re: [PATCHv2 1/5] sh_eth: add generic wake-on-lan support via magic packet
From: Sergei Shtylyov @ 2016-12-19 16:56 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Simon Horman, netdev, linux-renesas-soc, Geert Uytterhoeven
In-Reply-To: <20161219164159.GF21006@bigcity.dyn.berto.se>
Hello!
On 12/19/2016 07:41 PM, Niklas Söderlund wrote:
[...]
>>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
>>> index 05b0dc5..87640b9 100644
>>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
[...]
>>> index d050f37..4ceed00 100644
>>> --- a/drivers/net/ethernet/renesas/sh_eth.h
>>> +++ b/drivers/net/ethernet/renesas/sh_eth.h
>>> @@ -493,6 +493,7 @@ struct sh_eth_cpu_data {
>>> unsigned shift_rd0:1; /* shift Rx descriptor word 0 right by 16 */
>>> unsigned rmiimode:1; /* EtherC has RMIIMODE register */
>>> unsigned rtrate:1; /* EtherC has RTRATE register */
>>> + unsigned magic:1; /* EtherC has ECMR.PMDE and ECSR.MPD */
>>
>> After looking at the SH7734/63 manuals it became obvious that PMDE was a
>> result of typo, the bit is called MPDE actually, the current name doesn't
>> make sense anyway. Care to fix?
>
> Sure, I add fixup patch to the front of this series which cleans this up
> before adding WoL support.
That would be fine, TIA!
[...]
MBR, Sergei
^ permalink raw reply
* Re: ipv6: handle -EFAULT from skb_copy_bits
From: Dave Jones @ 2016-12-19 17:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20161217.104120.945262627572958024.davem@davemloft.net>
On Sat, Dec 17, 2016 at 10:41:20AM -0500, David Miller wrote:
> > It seems to be possible to craft a packet for sendmsg that triggers
> > the -EFAULT path in skb_copy_bits resulting in a BUG_ON that looks like:
> >
> > RIP: 0010:[<ffffffff817c6390>] [<ffffffff817c6390>] rawv6_sendmsg+0xc30/0xc40
> > RSP: 0018:ffff881f6c4a7c18 EFLAGS: 00010282
> > RAX: 00000000fffffff2 RBX: ffff881f6c681680 RCX: 0000000000000002
> > RDX: ffff881f6c4a7cf8 RSI: 0000000000000030 RDI: ffff881fed0f6a00
> > RBP: ffff881f6c4a7da8 R08: 0000000000000000 R09: 0000000000000009
> > R10: ffff881fed0f6a00 R11: 0000000000000009 R12: 0000000000000030
> > R13: ffff881fed0f6a00 R14: ffff881fee39ba00 R15: ffff881fefa93a80
> >
> > Call Trace:
> > [<ffffffff8118ba23>] ? unmap_page_range+0x693/0x830
> > [<ffffffff81772697>] inet_sendmsg+0x67/0xa0
> > [<ffffffff816d93f8>] sock_sendmsg+0x38/0x50
> > [<ffffffff816d982f>] SYSC_sendto+0xef/0x170
> > [<ffffffff816da27e>] SyS_sendto+0xe/0x10
> > [<ffffffff81002910>] do_syscall_64+0x50/0xa0
> > [<ffffffff817f7cbc>] entry_SYSCALL64_slow_path+0x25/0x25
> >
> > Handle this in rawv6_push_pending_frames and jump to the failure path.
> >
> > Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
>
> Hmmm, that's interesting. Becaue the code in __ip6_append_data(), which
> sets up the ->cork.base.length value, seems to be defensively trying to
> avoid this possibility.
>
> For example, it checks things like:
>
> if (cork->length + length > mtu - headersize && ipc6->dontfrag &&
> (sk->sk_protocol == IPPROTO_UDP ||
> sk->sk_protocol == IPPROTO_RAW)) {
>
> This is why the transport offset plus the length should never exceed
> the total length for that skb_copy_bits() call.
>
> Perhaps this protocol check in the code above is incomplete? Do you
> know what the sk->sk_protocol value was when that BUG triggered? That
> might shine some light on what is really happening here.
Hm.
sk_protocol = 7,
struct sock {
__sk_common = {
{
skc_addrpair = 0,
{
skc_daddr = 0,
skc_rcv_saddr = 0
}
},
{
skc_hash = 0,
skc_u16hashes = {0, 0}
},
{
skc_portpair = 458752,
{
skc_dport = 0,
skc_num = 7
}
},
skc_family = 10,
skc_state = 7 '\a',
skc_reuse = 1 '\001',
skc_reuseport = 0 '\000',
skc_ipv6only = 0 '\000',
skc_net_refcnt = 1 '\001',
skc_bound_dev_if = 0,
{
skc_bind_node = {
next = 0x0,
pprev = 0x0
},
skc_portaddr_node = {
next = 0x0,
pprev = 0x0
}
},
skc_prot = 0xffffffff81cf3bc0 <rawv6_prot>,
skc_net = {
net = 0xffffffff81ce78c0 <init_net>
},
skc_v6_daddr = {
in6_u = {
u6_addr8 = "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000",
u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0},
u6_addr32 = {0, 0, 0, 0}
}
},
},
skc_v6_rcv_saddr = {
in6_u = {
u6_addr8 = "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000",
u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0},
u6_addr32 = {0, 0, 0, 0}
}
},
skc_cookie = {
counter = 0
},
{
skc_flags = 256,
skc_listener = 0x100,
skc_tw_dr = 0x100
},
skc_dontcopy_begin = 0xffff881fd1ce9b68,
{
skc_node = {
next = 0x0,
pprev = 0x0
},
skc_nulls_node = {
next = 0x0,
pprev = 0x0
}
},
skc_tx_queue_mapping = -1,
{
skc_incoming_cpu = -1,
skc_rcv_wnd = 4294967295,
skc_tw_rcv_nxt = 4294967295
},
skc_refcnt = {
counter = 1
},
skc_dontcopy_end = 0xffff881fd1ce9b84,
{
skc_rxhash = 0,
skc_window_clamp = 0,
skc_tw_snd_nxt = 0
}
},
sk_lock = {
slock = {
{
rlock = {
raw_lock = {
val = {
counter = 0
}
}
}
}
},
owned = 1,
wq = {
lock = {
{
rlock = {
raw_lock = {
val = {
counter = 0
}
}
}
}
},
task_list = {
next = 0xffff881fd1ce9b98,
prev = 0xffff881fd1ce9b98
}
}
},
sk_receive_queue = {
next = 0xffff881fd1ce9ba8,
prev = 0xffff881fd1ce9ba8,
qlen = 0,
lock = {
{
rlock = {
raw_lock = {
val = {
counter = 0
}
}
}
}
}
},
sk_backlog = {
rmem_alloc = {
counter = 0
},
len = 0,
head = 0x0,
tail = 0x0
},
sk_forward_alloc = 0,
sk_txhash = 0,
sk_napi_id = 0,
sk_ll_usec = 0,
sk_drops = {
counter = 0
},
sk_rcvbuf = 1024000,
sk_filter = 0x0,
{
sk_wq = 0xffff881fc4b3ab00,
sk_wq_raw = 0xffff881fc4b3ab00
},
sk_policy = {0x0, 0x0},
sk_rx_dst = 0x0,
sk_dst_cache = 0x0,
sk_wmem_alloc = {
counter = 769
},
sk_omem_alloc = {
counter = 640
},
sk_sndbuf = 212992,
sk_write_queue = {
next = 0xffff881f6fc60b00,
prev = 0xffff881f6fc60b00,
qlen = 1,
lock = {
{
rlock = {
raw_lock = {
val = {
counter = 0
}
}
}
}
}
},
sk_shutdown = 0,
sk_no_check_tx = 0,
sk_no_check_rx = 0,
sk_userlocks = 0,
sk_protocol = 7,
sk_type = 3,
sk_wmem_queued = 0,
sk_allocation = 37748928,
sk_pacing_rate = 4294967295,
sk_max_pacing_rate = 4294967295,
sk_route_caps = 0,
sk_route_nocaps = 0,
sk_gso_type = 0,
sk_gso_max_size = 0,
sk_gso_max_segs = 0,
sk_rcvlowat = 1,
sk_lingertime = 0,
sk_error_queue = {
next = 0xffff881fd1ce9c88,
prev = 0xffff881fd1ce9c88,
qlen = 0,
lock = {
{
rlock = {
raw_lock = {
val = {
counter = 0
}
}
}
}
}
},
sk_prot_creator = 0xffffffff81cf3bc0 <rawv6_prot>,
sk_callback_lock = {
raw_lock = {
cnts = {
counter = 0
},
wait_lock = {
val = {
counter = 0
}
}
}
},
sk_err = 0,
sk_err_soft = 0,
sk_ack_backlog = 0,
sk_max_ack_backlog = 0,
sk_priority = 0,
sk_mark = 0,
sk_peer_pid = 0x0,
sk_peer_cred = 0x0,
sk_rcvtimeo = 9223372036854775807,
sk_sndtimeo = 9223372036854775807,
sk_timer = {
entry = {
next = 0x0,
pprev = 0x0
},
expires = 0,
function = 0x0,
data = 0,
flags = 4,
slack = -1,
start_pid = -1,
start_site = 0x0,
start_comm = "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
},
sk_stamp = {
tv64 = 1481510503238183349
},
sk_tsflags = 0,
sk_tskey = 0,
sk_socket = 0xffff881fd0d24b00,
sk_user_data = 0x0,
sk_frag = {
page = 0x0,
offset = 0,
size = 0
},
sk_send_head = 0x0,
sk_peek_off = -1,
sk_write_pending = 0,
sk_security = 0x0,
sk_cgrp_data = {
{
{
is_data = 48 '0',
padding = 109 'm',
prioidx = 33292,
classid = 4294967295
},
val = 18446744071596436784
}
},
sk_memcg = 0x0,
sk_state_change = 0xffffffff816dbed0 <sock_def_wakeup>,
sk_data_ready = 0xffffffff816dcd20 <sock_def_readable>,
sk_write_space = 0xffffffff816dcc90 <sock_def_write_space>,
sk_error_report = 0xffffffff816dcc30 <sock_def_error_report>,
sk_backlog_rcv = 0xffffffff817c5690 <rawv6_rcv_skb>,
sk_destruct = 0xffffffff81772460 <inet_sock_destruct>,
sk_reuseport_cb = 0x0
}
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Jason A. Donenfeld @ 2016-12-19 17:08 UTC (permalink / raw)
To: noloader
Cc: Netdev, kernel-hardening, LKML, Linux Crypto Mailing List,
David Laight, Ted Tso, Hannes Frederic Sowa, Linus Torvalds,
Eric Biggers, Tom Herbert, George Spelvin, Vegard Nossum,
Andi Kleen, David Miller, Andy Lutomirski, Jean-Philippe Aumasson,
Daniel J . Bernstein
In-Reply-To: <CAH8yC8nE5CLfbv8gCRCeiNW3JLCAB3062-6pNO8mEXJYcsFUsw@mail.gmail.com>
On Sat, Dec 17, 2016 at 3:55 PM, Jeffrey Walton <noloader@gmail.com> wrote:
> It may be prudent to include the endian reversal in the test to ensure
> big endian machines produce expected results. Some closely related
> testing on an old Apple PowerMac G5 revealed that result needed to be
> reversed before returning it to a caller.
The function [1] returns a u64. Originally I had it returning a
__le64, but that was considered unnecessary by many prior reviewers on
the list. It returns an integer. If you want uniform bytes out of it,
then use the endian conversion function, the same as you would do with
any other type of integer.
Additionally, this function is *not* meant for af_alg or any of the
crypto/* code. It's very unlikely to find a use there.
> Forgive my ignorance... I did not find reading on using the primitive
> in a PRNG. Does anyone know what Aumasson or Bernstein have to say?
> Aumasson's site does not seem to discuss the use case:
He's on this thread so I suppose he can speak up for himself. But in
my conversations with him, the primary take-away was, "seems okay to
me!". But please -- JP - correct me if I've misinterpreted.
^ permalink raw reply
* Re: [PATCH] stmmac: fix memory barriers
From: Joao Pinto @ 2016-12-19 17:10 UTC (permalink / raw)
To: David Miller, pavel
Cc: LinoSanfilippo, peppe.cavallaro, alexandre.torgue, linux-kernel,
netdev, niklas.cassel, Joao.Pinto
In-Reply-To: <20161219.110655.448567935176535028.davem@davemloft.net>
Hi,
I am trying to built net-next git tree and it is failing:
CC drivers/pnp/card.o
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function
‘stmmac_hw_fix_mac_speed’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:224:34: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
struct phy_device *phydev = priv->phydev;
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_eee_init’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:298:24: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
if (phy_init_eee(priv->phydev, 1)) {
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:330:44: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
priv->hw->mac->set_eee_pls(priv->hw, priv->phydev->link);
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_init_ptp’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:672:2: error: void value not
ignored as it ought to be
return stmmac_ptp_register(priv);
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_adjust_link’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:694:34: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
struct phy_device *phydev = priv->phydev;
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_init_phy’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:884:6: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
priv->phydev = phydev;
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_open’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1810:10: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
if (priv->phydev)
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1811:17: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
phy_start(priv->phydev);
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1858:10: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
if (priv->phydev)
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1859:22: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
phy_disconnect(priv->phydev);
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_release’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1878:10: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
if (priv->phydev) {
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1879:16: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
phy_stop(priv->phydev);
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1880:22: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
phy_disconnect(priv->phydev);
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1881:7: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
priv->phydev = NULL;
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_ioctl’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2883:12: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
if (!priv->phydev)
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2885:27: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
ret = phy_mii_ioctl(priv->phydev, rq, cmd);
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_suspend’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3438:10: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
if (priv->phydev)
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3439:16: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
phy_stop(priv->phydev);
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_resume’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3533:10: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
if (priv->phydev)
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3534:17: error: ‘struct
stmmac_priv’ has no member named ‘phydev’
phy_start(priv->phydev);
^
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_init_ptp’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:673:1: warning: control
reaches end of non-void function [-Wreturn-type]
}
^
CC drivers/pnp/driver.o
make[5]: *** [drivers/net/ethernet/stmicro/stmmac/stmmac_main.o] Error 1
make[4]: *** [drivers/net/ethernet/stmicro/stmmac] Error 2
make[3]: *** [drivers/net/ethernet/stmicro] Error 2
make[3]: *** Waiting for unfinished jobs....
CC drivers/pnp/resource.o
Thanks,
Joao
Às 4:06 PM de 12/19/2016, David Miller escreveu:
> From: Pavel Machek <pavel@ucw.cz>
> Date: Sun, 18 Dec 2016 21:38:12 +0100
>
>> Fix up memory barriers in stmmac driver. They are meant to protect
>> against DMA engine, so smp_ variants are certainly wrong, and dma_
>> variants are preferable.
>>
>> Signed-off-by: Pavel Machek <pavel@denx.de>
>
> Applied.
>
^ permalink raw reply
* Re: [PATCHv2 1/5] sh_eth: add generic wake-on-lan support via magic packet
From: Geert Uytterhoeven @ 2016-12-19 17:11 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Sergei Shtylyov, Simon Horman, netdev@vger.kernel.org,
Linux-Renesas
In-Reply-To: <20161219163904.GE21006@bigcity.dyn.berto.se>
Hi Niklas,
On Mon, Dec 19, 2016 at 5:39 PM, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
> On 2016-12-18 23:26:11 +0300, Sergei Shtylyov wrote:
>> On 12/12/2016 07:09 PM, Niklas Söderlund wrote:
>> > One quirk needed for WoL is that the module clock needs to be prevented
>> > from being switched off by Runtime PM. To keep the clock alive the
>>
>> I tried to find the code in question and failed, getting muddled in the
>> RPM maze. Could you point at this code for my education? :-)
>
> In my investigation I observed this (simplified) call graph with regards
> to clocks for suspend:
>
> pm_suspend
> pm_clk_suspend
> clk_disable
> clk_core_disable
> cpg_mstp_clock_disable
>
> The interesting function here are clk_core_disable(). In that function a
> 'enable_count' for each clock is decremented and the clock is only
> turned of if the count reaches zero, hence cpg_mstp_clock_disable() are
> only called if the counter reaches 0. At runtime the enable_count can be
> displayed by examining /sys/kernel/debug/clk/clk_summary.
>
> However the value for enable_count show at runtime are not the values
> which are used when the pm_clk_suspend() are called. For a clock to not
> be switched off when suspending the enable_count needs to incremented,
> which a few drivers do if they can be used as a wake-up source.
>
>>
>> > suspend callback need to call clk_enable() directly to increase the
>>
>> My main concern is why we need to manipulate the clock directly --
>> can't you call RPM to achieve the same effect?
>
> In my early attempts to keep the clock alive when suspending I used
> pm_clk_resume()/pm_clk_suspend() to increment/decrement the clock usage
> count. pm_clk_resume()/pm_clk_suspend() calls clk_enable()/clk_disable()
> for all clocks in the device's PM clock list, among other things.
>
> Geert pointed out to me that this might have side effects and to manages
> its clock directly is preferred. Looking how these functions are used at
> other places I can only agree with Geert that this feels like the wrong
> solution and a layer violation.
>> > usage count of the clock. Then when Runtime PM decreases the clock usage
>> > count it won't reach 0 and be switched off.
>>
>> You mean it does this even though we don't call pr_runtime_put_sync()
>> as done in sh_eth_close()?
>
> Yes.
>
> I had a look at the pm_runtime_* functions in include/linux/pm_runtime.h
> and drivers/base/power/runtime.c and could not find any clock handling.
> Maybe they only deal with power domains?
There should be a generic way to prevent a device from being suspended.
This will make sure the module clock is not disabled, and the power domain
(if applicable) is not powered down.
Note that the clock handling is a special form of power domain handling,
as it uses a clock domain.
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH] stmmac: fix memory barriers
From: Niklas Cassel @ 2016-12-19 17:19 UTC (permalink / raw)
To: Joao Pinto, David Miller, pavel
Cc: LinoSanfilippo, peppe.cavallaro, alexandre.torgue, linux-kernel,
netdev
In-Reply-To: <79efbe1a-bdc3-2aca-88a2-42a1b29f292d@synopsys.com>
On 12/19/2016 06:10 PM, Joao Pinto wrote:
> Hi,
>
> I am trying to built net-next git tree and it is failing:
>
> CC drivers/pnp/card.o
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function
> ‘stmmac_hw_fix_mac_speed’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:224:34: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> struct phy_device *phydev = priv->phydev;
Are you really building net-next?
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n224
The phy_device initializer does not appear to match your output.
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_eee_init’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:298:24: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> if (phy_init_eee(priv->phydev, 1)) {
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:330:44: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> priv->hw->mac->set_eee_pls(priv->hw, priv->phydev->link);
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_init_ptp’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:672:2: error: void value not
> ignored as it ought to be
> return stmmac_ptp_register(priv);
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_adjust_link’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:694:34: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> struct phy_device *phydev = priv->phydev;
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_init_phy’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:884:6: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> priv->phydev = phydev;
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_open’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1810:10: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> if (priv->phydev)
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1811:17: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> phy_start(priv->phydev);
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1858:10: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> if (priv->phydev)
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1859:22: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> phy_disconnect(priv->phydev);
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_release’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1878:10: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> if (priv->phydev) {
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1879:16: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> phy_stop(priv->phydev);
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1880:22: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> phy_disconnect(priv->phydev);
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1881:7: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> priv->phydev = NULL;
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_ioctl’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2883:12: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> if (!priv->phydev)
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2885:27: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> ret = phy_mii_ioctl(priv->phydev, rq, cmd);
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_suspend’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3438:10: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> if (priv->phydev)
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3439:16: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> phy_stop(priv->phydev);
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_resume’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3533:10: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> if (priv->phydev)
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3534:17: error: ‘struct
> stmmac_priv’ has no member named ‘phydev’
> phy_start(priv->phydev);
> ^
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_init_ptp’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:673:1: warning: control
> reaches end of non-void function [-Wreturn-type]
> }
> ^
> CC drivers/pnp/driver.o
> make[5]: *** [drivers/net/ethernet/stmicro/stmmac/stmmac_main.o] Error 1
> make[4]: *** [drivers/net/ethernet/stmicro/stmmac] Error 2
> make[3]: *** [drivers/net/ethernet/stmicro] Error 2
> make[3]: *** Waiting for unfinished jobs....
> CC drivers/pnp/resource.o
>
> Thanks,
> Joao
>
> Às 4:06 PM de 12/19/2016, David Miller escreveu:
>> From: Pavel Machek <pavel@ucw.cz>
>> Date: Sun, 18 Dec 2016 21:38:12 +0100
>>
>>> Fix up memory barriers in stmmac driver. They are meant to protect
>>> against DMA engine, so smp_ variants are certainly wrong, and dma_
>>> variants are preferable.
>>>
>>> Signed-off-by: Pavel Machek <pavel@denx.de>
>> Applied.
>>
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Jean-Philippe Aumasson @ 2016-12-19 17:19 UTC (permalink / raw)
To: Jason A. Donenfeld, noloader
Cc: Netdev, kernel-hardening, LKML, Linux Crypto Mailing List,
David Laight, Ted Tso, Hannes Frederic Sowa, Linus Torvalds,
Eric Biggers, Tom Herbert, George Spelvin, Vegard Nossum,
Andi Kleen, David Miller, Andy Lutomirski, Daniel J . Bernstein
In-Reply-To: <CAHmME9o6CFuQJEp3QJgkh78r5Z2F8NJnpTCCFUiSnAiJxPGCJQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]
Yeah you can use the PRF properties to build a DRBG, but that may not be
optimal in terms of performance.
On Mon, 19 Dec 2016 at 18:08, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> On Sat, Dec 17, 2016 at 3:55 PM, Jeffrey Walton <noloader@gmail.com>
> wrote:
> > It may be prudent to include the endian reversal in the test to ensure
> > big endian machines produce expected results. Some closely related
> > testing on an old Apple PowerMac G5 revealed that result needed to be
> > reversed before returning it to a caller.
>
> The function [1] returns a u64. Originally I had it returning a
> __le64, but that was considered unnecessary by many prior reviewers on
> the list. It returns an integer. If you want uniform bytes out of it,
> then use the endian conversion function, the same as you would do with
> any other type of integer.
>
> Additionally, this function is *not* meant for af_alg or any of the
> crypto/* code. It's very unlikely to find a use there.
>
>
> > Forgive my ignorance... I did not find reading on using the primitive
> > in a PRNG. Does anyone know what Aumasson or Bernstein have to say?
> > Aumasson's site does not seem to discuss the use case:
>
> He's on this thread so I suppose he can speak up for himself. But in
> my conversations with him, the primary take-away was, "seems okay to
> me!". But please -- JP - correct me if I've misinterpreted.
>
[-- Attachment #2: Type: text/html, Size: 2216 bytes --]
^ permalink raw reply
* RE: [PATCH v8 3/8] thunderbolt: Communication with the ICM (firmware)
From: Mario.Limonciello @ 2016-12-19 17:21 UTC (permalink / raw)
To: mika.westerberg, luto
Cc: amir.jer.levy, gregkh, andreas.noever, bhelgaas, corbet,
linux-kernel, linux-pci, netdev, linux-doc, thunderbolt-linux,
tomas.winkler, xiong.y.zhang
In-Reply-To: <20161219122407.GQ1460@lahna.fi.intel.com>
Dell - Internal Use - Confidential
>
> There is small problem, though. On non-Apple systems the host controller only
> appears when something is connected to thunderbolt ports. So the char device
> would not be there all the time. However, I think we can still notify the
> userspace by sending an extra uevent when we detect there is a PCIe device or
> inter-domain connection plugged in.
>
Why couldn't you just create it the first time a device is plugged into a Thunderbolt
port and leave it until the module is cleaned up? If the host controller goes to sleep
an event could be sent to the daemon to let it know it disappeared and not to expect
data on the char device for now, but leave the node around.
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Jason A. Donenfeld @ 2016-12-19 17:21 UTC (permalink / raw)
To: Theodore Ts'o, kernel-hardening, Jason, George Spelvin,
Andi Kleen, David Miller, David Laight, Daniel J . Bernstein,
Eric Biggers, Hannes Frederic Sowa, Jean-Philippe Aumasson,
Linux Crypto Mailing List, LKML, Andy Lutomirski, Netdev,
Tom Herbert, Linus Torvalds, Vegard Nossum
In-Reply-To: <20161217154152.5oug7mzb4tmfknwv@thunk.org>
Hi Ted,
On Sat, Dec 17, 2016 at 4:41 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote:
>> >> - Ted, Andy Lutorminski and I will try to figure out a construction of
>> >> get_random_long() that we all like.
>
> We don't have to find the most optimal solution right away; we can
> approach this incrementally, after all.
Thanks to your call for moderation. This is the impression I have too.
And with all the back and forth of these threads, I fear nothing will
get done. I'm going to collect the best ideas amongst all of these,
and try to get it merged. Then after that we can incrementally improve
on it.
David Miller -- would you merge something into your 4.11 tree? Seems
like you might be the guy for this, since the changes primarily affect
net/*.
Latest patches are here:
https://git.zx2c4.com/linux-dev/log/?h=siphash
> So long as we replace get_random_{long,int}() with something which is
> (a) strictly better in terms of security given today's use of MD5, and
> (b) which is strictly *faster* than the current construction on 32-bit
> and 64-bit systems, we can do that, and can try to make it be faster
> while maintaining some minimum level of security which is sufficient
> for all current users of get_random_{long,int}() and which can be
> clearly artificulated for future users of get_random_{long,int}().
>
> The main worry at this point I have is benchmarking siphash on a
> 32-bit system. It may be that simply batching the chacha20 output so
> that we're using the urandom construction more efficiently is the
> better way to go, since that *does* meet the criteron of strictly more
> secure and strictly faster than the current MD5 solution. I'm open to
> using siphash, but I want to see the the 32-bit numbers first.
Sure, I'll run some benchmarks and report back.
> As far as half-siphash is concerned, it occurs to me that the main
> problem will be those users who need to guarantee that output can't be
> guessed over a long period of time. For example, if you have a
> long-running process, then the output needs to remain unguessable over
> potentially months or years, or else you might be weakening the ASLR
> protections. If on the other hand, the hash table or the process will
> be going away in a matter of seconds or minutes, the requirements with
> respect to cryptographic strength go down significantly.
>
> Now, maybe this doesn't matter that much if we can guarantee (or make
> assumptions) that the attacker doesn't have unlimited access the
> output stream of get_random_{long,int}(), or if it's being used in an
> anti-DOS use case where it ultimately only needs to be harder than
> alternate ways of attacking the system.
The only acceptable usage of HalfSipHash is for hash table lookups
where top security isn't actually a goal. I'm still a bit queasy about
going with it, but George S has very aggressively been pursuing a
"save every last cycle" agenda, which makes sense given how
performance sensitive certain hash tables are, and so I suspect this
could be an okay compromise between performance and security. But,
only for hash tables. Certainly not for the RNG.
>
> Rekeying every five minutes doesn't necessarily help the with respect
> to ASLR, but it might reduce the amount of the output stream that
> would be available to the attacker in order to be able to attack the
> get_random_{long,int}() generator, and it also reduces the value of
> doing that attack to only compromising the ASLR for those processes
> started within that five minute window.
The current implemention of get_random_int/long in my branch uses
128-bit key siphash, so the chances of compromising the key are pretty
much nil. The periodic rekeying is to protect against direct-ram
attacks or other kernel exploits -- a concern brought up by Andy.
With siphash, which takes a 128-bit key, if you got an RNG output once
every picosecond, I believe it would take approximately 10^19 years...
Jason
^ permalink raw reply
* Re: [PATCH] stmmac: fix memory barriers
From: Joao Pinto @ 2016-12-19 17:25 UTC (permalink / raw)
To: Niklas Cassel, Joao Pinto, David Miller, pavel
Cc: LinoSanfilippo, peppe.cavallaro, alexandre.torgue, linux-kernel,
netdev
In-Reply-To: <886b24a5-6d54-4bd5-2143-d8f2cbe6c746@axis.com>
Às 5:19 PM de 12/19/2016, Niklas Cassel escreveu:
> On 12/19/2016 06:10 PM, Joao Pinto wrote:
>> Hi,
>>
>> I am trying to built net-next git tree and it is failing:
>>
>> CC drivers/pnp/card.o
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function
>> ‘stmmac_hw_fix_mac_speed’:
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:224:34: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> struct phy_device *phydev = priv->phydev;
>
> Are you really building net-next?
> https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.org_cgit_linux_kernel_git_davem_net-2Dnext.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n224&d=DgID-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=4j4xIgbdV5gZT6wNKZXizwY4xE3ZoFeyGzRKeNvDsN0&s=vY4rQn8skcuhsdzk3vdZEyYF2TL8r5Dxc0gDGRjqLTQ&e=
>
> The phy_device initializer does not appear to match your output.
Spookie! The fetch process left half merge! I will try it again! Thanks!
>
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_eee_init’:
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:298:24: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> if (phy_init_eee(priv->phydev, 1)) {
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:330:44: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> priv->hw->mac->set_eee_pls(priv->hw, priv->phydev->link);
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_init_ptp’:
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:672:2: error: void value not
>> ignored as it ought to be
>> return stmmac_ptp_register(priv);
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_adjust_link’:
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:694:34: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> struct phy_device *phydev = priv->phydev;
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_init_phy’:
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:884:6: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> priv->phydev = phydev;
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_open’:
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1810:10: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> if (priv->phydev)
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1811:17: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> phy_start(priv->phydev);
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1858:10: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> if (priv->phydev)
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1859:22: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> phy_disconnect(priv->phydev);
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_release’:
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1878:10: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> if (priv->phydev) {
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1879:16: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> phy_stop(priv->phydev);
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1880:22: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> phy_disconnect(priv->phydev);
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1881:7: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> priv->phydev = NULL;
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_ioctl’:
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2883:12: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> if (!priv->phydev)
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2885:27: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> ret = phy_mii_ioctl(priv->phydev, rq, cmd);
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_suspend’:
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3438:10: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> if (priv->phydev)
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3439:16: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> phy_stop(priv->phydev);
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_resume’:
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3533:10: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> if (priv->phydev)
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3534:17: error: ‘struct
>> stmmac_priv’ has no member named ‘phydev’
>> phy_start(priv->phydev);
>> ^
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function ‘stmmac_init_ptp’:
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:673:1: warning: control
>> reaches end of non-void function [-Wreturn-type]
>> }
>> ^
>> CC drivers/pnp/driver.o
>> make[5]: *** [drivers/net/ethernet/stmicro/stmmac/stmmac_main.o] Error 1
>> make[4]: *** [drivers/net/ethernet/stmicro/stmmac] Error 2
>> make[3]: *** [drivers/net/ethernet/stmicro] Error 2
>> make[3]: *** Waiting for unfinished jobs....
>> CC drivers/pnp/resource.o
>>
>> Thanks,
>> Joao
>>
>> Às 4:06 PM de 12/19/2016, David Miller escreveu:
>>> From: Pavel Machek <pavel@ucw.cz>
>>> Date: Sun, 18 Dec 2016 21:38:12 +0100
>>>
>>>> Fix up memory barriers in stmmac driver. They are meant to protect
>>>> against DMA engine, so smp_ variants are certainly wrong, and dma_
>>>> variants are preferable.
>>>>
>>>> Signed-off-by: Pavel Machek <pavel@denx.de>
>>> Applied.
>>>
>
^ permalink raw reply
* HalfSipHash Acceptable Usage
From: Jason A. Donenfeld @ 2016-12-19 17:32 UTC (permalink / raw)
To: Jean-Philippe Aumasson
Cc: Theodore Ts'o, Hannes Frederic Sowa, LKML, Eric Biggers,
Daniel J . Bernstein, David Laight, David Miller, Andi Kleen,
George Spelvin, kernel-hardening, Andy Lutomirski,
Linux Crypto Mailing List, Tom Herbert, Vegard Nossum, Netdev,
Linus Torvalds
Hi JP,
With the threads getting confusing, I've been urged to try and keep
the topics and threads more closely constrained. Here's where we're
at, and here's the current pressing security concern. It'd be helpful
to have a definitive statement on what you think is best, so we can
just build on top of that, instead of getting lost in the chorus of
opinions.
1) Anything that requires actual long-term security will use
SipHash2-4, with the 64-bit output and the 128-bit key. This includes
things like TCP sequence numbers. This seems pretty uncontroversial to
me. Seem okay to you?
2) People seem to want something competitive, performance-wise, with
jhash if it's going to replace jhash. The kernel community
instinctively pushes back on anything that could harm performance,
especially in networking and in critical data structures, so there
have been some calls for something faster than SipHash. So, questions
regarding this:
2a) George thinks that HalfSipHash on 32-bit systems will have roughly
comparable speed as SipHash on 64-bit systems, so the idea would be to
use HalfSipHash on 32-bit systems' hash tables and SipHash on 64-bit
systems' hash tables. The big obvious question is: does HalfSipHash
have a sufficient security margin for hashtable usage and hashtable
attacks? I'm not wondering about the security margin for other usages,
but just of the hashtable usage. In your opinion, does HalfSipHash cut
it?
2b) While I certainly wouldn't consider making the use case in
question (1) employ a weaker function, for this question (2), there
has been some discussion about using HalfSipHash1-3 (or SipHash1-3 on
64-bit) instead of 2-4. So, the same question is therefore posed:
would using HalfSipHash1-3 give a sufficient security margin for
hashtable usage and hashtable attacks?
My plan is essentially to implement things according to your security
recommendation. The thread started with me pushing a heavy duty
security solution -- SipHash2-4 -- for _everything_. I've received
understandable push back on that notion for certain use cases. So now
I'm trying to discover what the most acceptable compromise is. Your
answers on (2a) and (2b) will direct that compromise.
Thanks again,
Jason
^ permalink raw reply
* Re: [PATCH net] virtio_net: reject XDP programs using header adjustment
From: John Fastabend @ 2016-12-19 17:50 UTC (permalink / raw)
To: Jakub Kicinski, netdev; +Cc: kafai, daniel, alexei.starovoitov, mst
In-Reply-To: <20161219150500.2600-1-jakub.kicinski@netronome.com>
On 16-12-19 07:05 AM, Jakub Kicinski wrote:
> commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
> added a new XDP helper to prepend and remove data from a frame.
> Make virtio_net reject programs making use of this helper until
> proper support is added.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> drivers/net/virtio_net.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 08327e005ccc..db761f37783e 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1677,6 +1677,11 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
> u16 xdp_qp = 0, curr_qp;
> int i, err;
>
> + if (prog && prog->xdp_adjust_head) {
> + netdev_warn(dev, "Does not support bpf_xdp_adjust_head()\n");
> + return -EOPNOTSUPP;
> + }
> +
> if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO4) ||
> virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO6)) {
> netdev_warn(dev, "can't set XDP while host is implementing LRO, disable LRO first\n");
>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Thanks patch looks good. Alternatively we could push a "bug fix" to
support the adjust header feature depending on how DaveM and MST feel
about that. I don't have a strong opinion but I have the patch on my
queue it just needs some more testing. The adjust header bits were
merged in between some of the later versions of the patch which is how
this check got missed.
Thanks,
John
^ permalink raw reply
* Re: Synopsys Ethernet QoS
From: Niklas Cassel @ 2016-12-19 17:58 UTC (permalink / raw)
To: Pavel Machek
Cc: Giuseppe CAVALLARO, Joao Pinto, Florian Fainelli, Andy Shevchenko,
David Miller, larper, rabinv, netdev, CARLOS.PALMINHA, Jie.Deng1,
Stephen Warren
In-Reply-To: <20161214125735.GA19542@amd>
On 12/14/2016 01:57 PM, Pavel Machek wrote:
> Hi!
>
>> So if there is a long time before handling interrupts,
>> I guess that it makes sense that one stream could
>> get an advantage in the net scheduler.
>>
>> If I find the time, and if no one beats me to it, I will try to replace
>> the normal timers with HR timers + a smaller default timeout.
>>
> Can you try something like this? Highres timers will be needed, too,
> but this fixes the logic problem.
>
> You'll need to apply it twice as code is copy&pasted.
>
> Best regards,
Hello Pavel
If I first apply your other fix "stmmac: fix memory barriers",
then I can apply this fix without getting a netdev watchdog timeout on tx queue0,
and everything appears to work as it should.
Regarding to fairness, I can't really see a difference, with or without your patch.
I've noticed that for TX, the streams actually stabilize after 5 seconds or so,
but with the default test length of 10 seconds, it's easy to get confused
by the test result summary. So I guess from a fairness point of view,
TX is not really a problem.
For RX fairness, it is very much a real issue. The streams never stabilize.
One key difference is that RX coalescing is implemented by using the
RX watchdog.
Here is an iperf3 run that went for 30 seconds:
[ 4] 0.00-30.00 sec 1.54 GBytes 440 Mbits/sec 0 sender
[ 4] 0.00-30.00 sec 1.54 GBytes 440 Mbits/sec receiver
[ 6] 0.00-30.00 sec 600 MBytes 168 Mbits/sec 0 sender
[ 6] 0.00-30.00 sec 599 MBytes 168 Mbits/sec receiver
[ 8] 0.00-30.00 sec 1.17 GBytes 334 Mbits/sec 0 sender
[ 8] 0.00-30.00 sec 1.17 GBytes 334 Mbits/sec receiver
[SUM] 0.00-30.00 sec 3.29 GBytes 942 Mbits/sec 0 sender
[SUM] 0.00-30.00 sec 3.29 GBytes 942 Mbits/sec receiver
> Pavel
>
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>
> */
> priv->tx_count_frames += nfrags + 1;
> if (likely(priv->tx_coal_frames > priv->tx_count_frames)) {
> - mod_timer(&priv->txtimer,
> - STMMAC_COAL_TIMER(priv->tx_coal_timer));
> + if (priv->tx_count_frames == nfrags + 1)
> + mod_timer(&priv->txtimer,
> + STMMAC_COAL_TIMER(priv->tx_coal_timer));
> } else {
> priv->tx_count_frames = 0;
> priv->hw->desc->set_tx_ic(desc);
>
>
^ permalink raw reply
* Re: Soft lockup in tc_classify
From: Cong Wang @ 2016-12-19 17:58 UTC (permalink / raw)
To: Shahar Klein
Cc: Or Gerlitz, Daniel Borkmann, Linux Netdev List, Roi Dayan,
David Miller, Jiri Pirko, John Fastabend, Hadar Hen Zion
In-Reply-To: <18a64d65-1241-6c72-8333-47b0ae933139@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]
Hello,
On Mon, Dec 19, 2016 at 8:39 AM, Shahar Klein <shahark@mellanox.com> wrote:
>
>
> On 12/13/2016 12:51 AM, Cong Wang wrote:
>>
>> On Mon, Dec 12, 2016 at 1:18 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>>
>>> On Mon, Dec 12, 2016 at 3:28 PM, Daniel Borkmann <daniel@iogearbox.net>
>>> wrote:
>>>
>>>> Note that there's still the RCU fix missing for the deletion race that
>>>> Cong will still send out, but you say that the only thing you do is to
>>>> add a single rule, but no other operation in involved during that test?
>>>
>>>
>>> What's missing to have the deletion race fixed? making a patch or
>>> testing to a patch which was sent?
>>
>>
>> If you think it would help for this problem, here is my patch rebased
>> on the latest net-next.
>>
>> Again, I don't see how it could help this case yet, especially I don't
>> see how we could have a loop in this singly linked list.
>>
>
> I've applied cong's patch and hit a different lockup(full log attached):
Are you sure this is really different? For me, it is still inside the loop
in tc_classify(), with only a slightly different offset.
>
> Daniel suggested I'll add a print:
> case RTM_DELTFILTER:
> - err = tp->ops->delete(tp, fh);
> + printk(KERN_ERR "DEBUGG:SK %s:%d\n", __func__, __LINE__);
> + err = tp->ops->delete(tp, fh, &last);
> if (err == 0) {
>
> and I couldn't see this print in the output.....
Hmm, that is odd, if this never prints, then my patch should not make any
difference.
There are still two other cases where we could change tp->next, so do you
mind to add two more printk's for debugging?
Attached is the delta patch.
Thanks!
[-- Attachment #2: tc-filter-debug.diff --]
[-- Type: text/plain, Size: 880 bytes --]
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index f9179e0..45bfe9f 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -317,6 +317,8 @@ static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n)
if (n->nlmsg_type == RTM_DELTFILTER && t->tcm_handle == 0) {
struct tcf_proto *next = rtnl_dereference(tp->next);
+ printk(KERN_ERR "DEBUGG:SK delete filter by: %pf\n", tp->ops->get);
+
RCU_INIT_POINTER(*back, next);
tfilter_notify(net, skb, n, tp, fh,
@@ -370,6 +372,7 @@ static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n)
n->nlmsg_flags & NLM_F_CREATE ? TCA_ACT_NOREPLACE : TCA_ACT_REPLACE);
if (err == 0) {
if (tp_created) {
+ printk(KERN_ERR "DEBUGG:SK add/change filter by: %pf\n", tp->ops->change);
RCU_INIT_POINTER(tp->next, rtnl_dereference(*back));
rcu_assign_pointer(*back, tp);
}
^ permalink raw reply related
* Re: ovs internal_dev mtu
From: Cong Wang @ 2016-12-19 18:01 UTC (permalink / raw)
To: nickcooper-zhangtonghao; +Cc: Linux Kernel Network Developers
In-Reply-To: <E0899132-14F7-45F9-8F02-94421B595D4E@gmail.com>
On Mon, Dec 19, 2016 at 12:59 AM, nickcooper-zhangtonghao
<nic.tongh@gmail.com> wrote:
> The upstream net-next has removed the “internal_dev_change_mtu”.
> It will be ok for ovs(e.g. mtu_request) ? I think that code should
> be keep. Can you provide more information ？
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91572088e3fdbf4fe31cf397926d8b890fdb3237
^ permalink raw reply
* RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: George Spelvin @ 2016-12-19 18:10 UTC (permalink / raw)
To: David.Laight, linux, tom
Cc: ak, davem, djb, ebiggers3, hannes, Jason, jeanphilippe.aumasson,
kernel-hardening, linux-crypto, linux-kernel, luto, netdev,
torvalds, tytso, vegard.nossum
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB0242669@AcuExch.aculab.com>
David Laight wrote:
> From: George Spelvin
...
>> uint32_t
>> hsiphash24(char const *in, size_t len, uint32_t const key[2])
>> {
>> uint32_t c = key[0];
>> uint32_t d = key[1];
>> uint32_t a = 0x6c796765 ^ 0x736f6d65;
>> uint32_t b = d ^ 0x74656462 ^ 0x646f7261;
> I've not looked closely, but is that (in some sense) duplicating
> the key length?
> So you could set a = key[2] and b = key[3] and still have an
> working hash - albeit not exactly the one specified.
That's tempting, but not necessarily effective. (A similar unsuccesful
idea can be found in discussions of "DES with independent round keys".
Or see the design discussion of Salsa20 and the constants in its input.)
You can increase the key size, but that might not increase the *security*
any.
The big issue is that there are a *lot* of square root attack in
cryptanalysis. Because SipHash's state is twice the size of the key,
such an attack will have the same complexity as key exhaustion and need
not be considered. To make a stronger security claim, you need to start
working through them all and show that they don't apply.
For SipHash in particular, an important property is asymmetry of the
internal state. That's what duplicating the key with XORs guarantees.
If the two halves of the state end up identical, the mixing is much
weaker.
Now the probability of ending up in a "mirror state" is the square
root of the state size (1 in 2^64 for HalfSipHash's 128-bit state),
which is the same probability as guessing a key, so it's not a
problem that has to be considered when making a 64-bit security claim.
But if you want a higher security level, you have to think about
what can happen.
That said, I have been thinking very hard about
a = c ^ 0x48536970; /* 'HSip' */
d = key[2];
By guaranteeing that a and c are different, we get the desired
asymmetry, and the XOR of b and d is determined by the first word of
the message anyway, so this isn't weakening anything.
96 bits is far beyond the reach of any brute-force attack, and if a
more sophisticated 64-bit attack exists, it's at least out of the reach
of the script kiddies, and will almost certainly have a non-negligible
constant factor and more limits in when it can be applied.
> Is it worth using the 32bit hash for IP addresses on 64bit systems that
> can't do misaligned accessed?
Not a good idea. To hash 64 bits of input:
* Full SipHash has to do two loads, a shift, an or, and two rounds of mixing.
* HalfSipHash has to do a load, two rounds, another load, and two more rounds.
In other words, in addition to being less secure, it's half the speed.
Also, what systems are you thinking about? x86, ARMv8, PowerPC, and
S390 (and ia64, if anyone cares) all handle unaligned loads. MIPS has
efficient support. Alpha and HPPA are for retrocomputing fans, not
people who care about performance.
So you're down to SPARC. Which conveniently has the same maintainer as
the networking code, so I figure DaveM can take care of that himself. :-)
^ permalink raw reply
* Re: [upstream-release] [PATCH net v3 2/4] powerpc: fsl/fman: remove fsl, fman from of_device_ids[]
From: Scott Wood @ 2016-12-19 19:46 UTC (permalink / raw)
To: madalin.bucur, netdev; +Cc: mpe, linuxppc-dev, linux-kernel, davem
In-Reply-To: <1482164013-6111-3-git-send-email-madalin.bucur@nxp.com>
On Mon, 2016-12-19 at 18:13 +0200, Madalin Bucur wrote:
> The fsl/fman drivers will use of_platform_populate() on all
> supported platforms. Call of_platform_populate() to probe the
> FMan sub-nodes.
>
> Signed-off-by: Igal Liberman <igal.liberman@freescale.com>
> Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
> ---
> arch/powerpc/platforms/85xx/corenet_generic.c | 3 ---
> drivers/net/ethernet/freescale/fman/fman.c | 8 ++++++++
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
> b/arch/powerpc/platforms/85xx/corenet_generic.c
> index 1179115..824b7f1 100644
> --- a/arch/powerpc/platforms/85xx/corenet_generic.c
> +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
> @@ -117,9 +117,6 @@ static const struct of_device_id of_device_ids[] = {
> {
> .compatible = "fsl,qe",
> },
> - {
> - .compatible = "fsl,fman",
> - },
> /* The following two are for the Freescale hypervisor */
> {
> .name = "hypervisor",
For this part:
Acked-by: Scott Wood <oss@buserror.net>
> diff --git a/drivers/net/ethernet/freescale/fman/fman.c
> b/drivers/net/ethernet/freescale/fman/fman.c
> index dafd9e1..0b7f711 100644
> --- a/drivers/net/ethernet/freescale/fman/fman.c
> +++ b/drivers/net/ethernet/freescale/fman/fman.c
> @@ -2868,6 +2868,14 @@ static struct fman *read_dts_node(struct
> platform_device *of_dev)
>
> fman->dev = &of_dev->dev;
>
> + /* call of_platform_populate in order to probe sub-nodes on arm64
> */
> + err = of_platform_populate(fm_node, NULL, NULL, &of_dev->dev);
> + if (err) {
> + dev_err(&of_dev->dev, "%s: of_platform_populate()
> failed\n",
> + __func__);
> + goto fman_free;
> + }
The "on arm64" comment is no longer accurate (and the rest of the comment
seems unnecessary).
-Scott
^ permalink raw reply
* Re: ipv6: handle -EFAULT from skb_copy_bits
From: David Miller @ 2016-12-19 19:48 UTC (permalink / raw)
To: davej; +Cc: netdev
In-Reply-To: <20161219170320.nnezhql2vj5mrrrp@codemonkey.org.uk>
From: Dave Jones <davej@codemonkey.org.uk>
Date: Mon, 19 Dec 2016 12:03:20 -0500
> On Sat, Dec 17, 2016 at 10:41:20AM -0500, David Miller wrote:
>
> > > It seems to be possible to craft a packet for sendmsg that triggers
> > > the -EFAULT path in skb_copy_bits resulting in a BUG_ON that looks like:
> > >
> > > RIP: 0010:[<ffffffff817c6390>] [<ffffffff817c6390>] rawv6_sendmsg+0xc30/0xc40
> > > RSP: 0018:ffff881f6c4a7c18 EFLAGS: 00010282
> > > RAX: 00000000fffffff2 RBX: ffff881f6c681680 RCX: 0000000000000002
> > > RDX: ffff881f6c4a7cf8 RSI: 0000000000000030 RDI: ffff881fed0f6a00
> > > RBP: ffff881f6c4a7da8 R08: 0000000000000000 R09: 0000000000000009
> > > R10: ffff881fed0f6a00 R11: 0000000000000009 R12: 0000000000000030
> > > R13: ffff881fed0f6a00 R14: ffff881fee39ba00 R15: ffff881fefa93a80
> > >
> > > Call Trace:
> > > [<ffffffff8118ba23>] ? unmap_page_range+0x693/0x830
> > > [<ffffffff81772697>] inet_sendmsg+0x67/0xa0
> > > [<ffffffff816d93f8>] sock_sendmsg+0x38/0x50
> > > [<ffffffff816d982f>] SYSC_sendto+0xef/0x170
> > > [<ffffffff816da27e>] SyS_sendto+0xe/0x10
> > > [<ffffffff81002910>] do_syscall_64+0x50/0xa0
> > > [<ffffffff817f7cbc>] entry_SYSCALL64_slow_path+0x25/0x25
> > >
> > > Handle this in rawv6_push_pending_frames and jump to the failure path.
> > >
> > > Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
> >
> > Hmmm, that's interesting. Becaue the code in __ip6_append_data(), which
> > sets up the ->cork.base.length value, seems to be defensively trying to
> > avoid this possibility.
> >
> > For example, it checks things like:
> >
> > if (cork->length + length > mtu - headersize && ipc6->dontfrag &&
> > (sk->sk_protocol == IPPROTO_UDP ||
> > sk->sk_protocol == IPPROTO_RAW)) {
> >
> > This is why the transport offset plus the length should never exceed
> > the total length for that skb_copy_bits() call.
> >
> > Perhaps this protocol check in the code above is incomplete? Do you
> > know what the sk->sk_protocol value was when that BUG triggered? That
> > might shine some light on what is really happening here.
>
> Hm.
> sk_protocol = 7,
So, some arbitrary value.
Obviously, the test above intends to handle RAW sockets and that is exactly
what we have here.
A raw socket gets whatever the user specified as 'protocol' at create
time as the sk->sk_protocol value.
One thing that's interesting is that if the user picks "IPPROTO_RAW"
as the value of 'protocol' we set inet->hdrincl to 1.
The user can also set inet->hdrincl to 1 or 0 via setsockopt().
I think this is part of the problem. The test above means to check
for "RAW socket with hdrincl set" and is trying to do this more simply.
But because setsockopt() can set this arbitrarily, testing sk_protocol
alone isn't enough.
So changing:
sk->sk_protocol == IPPROTO_RAW
into something like:
(sk->sk_socket->type == SOCK_RAW && inet_sk(sk)->hdrincl)
should correct the test.
That is because this hdrincl thing is what controls which code path we
take in rawv6_sendmsg():
if (inet->hdrincl)
err = rawv6_send_hdrinc(sk, msg, len, &fl6, &dst, msg->msg_flags);
else {
ipc6.opt = opt;
lock_sock(sk);
err = ip6_append_data(sk, raw6_getfrag, &rfv,
len, 0, &ipc6, &fl6, (struct rt6_info *)dst,
msg->msg_flags, &sockc);
if (err)
ip6_flush_pending_frames(sk);
else if (!(msg->msg_flags & MSG_MORE))
err = rawv6_push_pending_frames(sk, &fl6, rp);
release_sock(sk);
}
You can test if the change I suggest above works.
^ permalink raw reply
* Re: [PATCH net] virtio_net: reject XDP programs using header adjustment
From: David Miller @ 2016-12-19 20:08 UTC (permalink / raw)
To: john.fastabend
Cc: jakub.kicinski, netdev, kafai, daniel, alexei.starovoitov, mst
In-Reply-To: <58581E01.7070902@gmail.com>
From: John Fastabend <john.fastabend@gmail.com>
Date: Mon, 19 Dec 2016 09:50:57 -0800
> On 16-12-19 07:05 AM, Jakub Kicinski wrote:
>> commit 17bedab27231 ("bpf: xdp: Allow head adjustment in XDP prog")
>> added a new XDP helper to prepend and remove data from a frame.
>> Make virtio_net reject programs making use of this helper until
>> proper support is added.
>>
>> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>> ---
>> drivers/net/virtio_net.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 08327e005ccc..db761f37783e 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -1677,6 +1677,11 @@ static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog)
>> u16 xdp_qp = 0, curr_qp;
>> int i, err;
>>
>> + if (prog && prog->xdp_adjust_head) {
>> + netdev_warn(dev, "Does not support bpf_xdp_adjust_head()\n");
>> + return -EOPNOTSUPP;
>> + }
>> +
>> if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO4) ||
>> virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO6)) {
>> netdev_warn(dev, "can't set XDP while host is implementing LRO, disable LRO first\n");
>>
>
> Acked-by: John Fastabend <john.r.fastabend@intel.com>
>
> Thanks patch looks good. Alternatively we could push a "bug fix" to
> support the adjust header feature depending on how DaveM and MST feel
> about that. I don't have a strong opinion but I have the patch on my
> queue it just needs some more testing. The adjust header bits were
> merged in between some of the later versions of the patch which is how
> this check got missed.
I would like to avoid inconsistent XDP feature support amongst drivers
as much as possible.
^ permalink raw reply
* Re: Soft lockup in tc_classify
From: Shahar Klein @ 2016-12-19 16:39 UTC (permalink / raw)
To: Cong Wang, Or Gerlitz
Cc: shahark, Daniel Borkmann, Linux Netdev List, Roi Dayan,
David Miller, Jiri Pirko, John Fastabend, Hadar Hen Zion,
Daniel Borkmann
In-Reply-To: <CAM_iQpVJ_Y5bB-RP2S2tK7sPNo6Atwcz5Ud8sG6bwDOSnq4NnA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]
On 12/13/2016 12:51 AM, Cong Wang wrote:
> On Mon, Dec 12, 2016 at 1:18 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Mon, Dec 12, 2016 at 3:28 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>>
>>> Note that there's still the RCU fix missing for the deletion race that
>>> Cong will still send out, but you say that the only thing you do is to
>>> add a single rule, but no other operation in involved during that test?
>>
>> What's missing to have the deletion race fixed? making a patch or
>> testing to a patch which was sent?
>
> If you think it would help for this problem, here is my patch rebased
> on the latest net-next.
>
> Again, I don't see how it could help this case yet, especially I don't
> see how we could have a loop in this singly linked list.
>
I've applied cong's patch and hit a different lockup(full log attached):
[ 264.725414] RIP: 0010:fl_classify+0x1f1/0x2b0 [cls_flower]
(gdb) list *(fl_classify+0x1f1)
0x1591 is in fl_classify (net/sched/cls_flower.c:187).
182 if (f && !tc_skip_sw(f->flags)) {
183 *res = f->res;
184 return tcf_exts_exec(skb, &f->exts, res);
185 }
186 return -1;
187 }
188
189 static int fl_init(struct tcf_proto *tp)
190 {
191 struct cls_fl_head *head;
(gdb)
Daniel suggested I'll add a print:
case RTM_DELTFILTER:
- err = tp->ops->delete(tp, fh);
+ printk(KERN_ERR "DEBUGG:SK %s:%d\n", __func__, __LINE__);
+ err = tp->ops->delete(tp, fh, &last);
if (err == 0) {
and I couldn't see this print in the output.....
[-- Attachment #2: lockup_with_congs_patch --]
[-- Type: text/plain, Size: 16806 bytes --]
[ 238.507670] GACT probability on
[ 264.573942] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:4867]
[ 264.582875] Modules linked in: act_gact act_mirred openvswitch nf_conntrack_ipv6 nf_nat_ipv6 nf_defrag_ipv6 vfio_pci vfio_virqfd vfio_iommu_type1 vfio cls_flower mlx5_ib mlx5_core devlink sch_ingress nfsv3 nfs fscache xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat libcrc32c nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun ebtable_filter ebtables ip6table_filter ip6_tables netconsole bridge stp llc rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm intel_rapl sb_edac edac_core x86_pkg_temp_thermal coretemp kvm_intel kvm ib_core irqbypass crct10dif_pclmul crc32_pclmul igb ptp iTCO_wdt pps_core crc32c_intel joydev i2c_algo_bit ghash_clmulni_intel iTCO_vendor_support pcspkr i2c_i801 mei_me ipmi_ssif ioatdma shpchp tpm_tis i2c_smbus tpm_tis_core dca tpm mei lpc_ich ipmi_si ipmi_msghandler wmi nfsd target_core_mod auth_rpcgss nfs_acl lockd grace sunrpc isci libsas serio_raw scsi_transport_sas [last unloaded: devlink]
[ 264.703539] CPU: 0 PID: 4867 Comm: modprobe Not tainted 4.9.0+ #27
[ 264.710766] Hardware name: Supermicro X9DRW/X9DRW, BIOS 3.0a 08/08/2013
[ 264.718475] task: ffff89916ad09d80 task.stack: ffffa36f44510000
[ 264.725414] RIP: 0010:fl_classify+0x1f1/0x2b0 [cls_flower]
[ 264.731863] RSP: 0018:ffff89916fa03ad8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
[ 264.740971] RAX: 00000000ffffffff RBX: ffff89913f522100 RCX: 0000000000000000
[ 264.749265] RDX: ffff89916fa03c98 RSI: ffff89915bd743c0 RDI: ffff89913f522100
[ 264.757558] RBP: ffff89916fa03c28 R08: 000000000000270f R09: 0000000000000000
[ 264.765852] R10: 0000000000000000 R11: 0000000000000004 R12: ffff89916fa03c98
[ 264.774144] R13: ffff89913ecc7c00 R14: ffff89915bd743c0 R15: 0000000000000001
[ 264.782440] FS: 00007f74f2f5e700(0000) GS:ffff89916fa00000(0000) knlGS:0000000000000000
[ 264.792066] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 264.798809] CR2: 00007f74f2491480 CR3: 000000043f3f8000 CR4: 00000000000426f0
[ 264.807102] Call Trace:
[ 264.810151] <IRQ>
[ 264.812717] ? handle_edge_irq+0x87/0x130
[ 264.817504] ? handle_irq+0xab/0x130
[ 264.821808] ? irq_exit+0x77/0xe0
[ 264.825828] ? irq_exit+0x77/0xe0
[ 264.829849] ? do_IRQ+0x51/0xd0
[ 264.833664] ? common_interrupt+0x93/0x93
[ 264.838462] tc_classify+0x78/0x120
[ 264.842679] __netif_receive_skb_core+0x623/0xa00
[ 264.848264] ? udp4_gro_receive+0x10b/0x2d0
[ 264.853253] __netif_receive_skb+0x18/0x60
[ 264.858150] netif_receive_skb_internal+0x40/0xb0
[ 264.863723] napi_gro_receive+0xcd/0x120
[ 264.868437] mlx5e_handle_rx_cqe_rep+0x61b/0x890 [mlx5_core]
[ 264.875105] ? kvm_irq_delivery_to_apic+0x2c0/0x2c0 [kvm]
[ 264.881462] mlx5e_poll_rx_cq+0x83/0x840 [mlx5_core]
[ 264.887333] mlx5e_napi_poll+0x89/0x480 [mlx5_core]
[ 264.893102] net_rx_action+0x260/0x3c0
[ 264.897610] __do_softirq+0xc9/0x28c
[ 264.901922] irq_exit+0xd7/0xe0
[ 264.905748] do_IRQ+0x51/0xd0
[ 264.909380] common_interrupt+0x93/0x93
[ 264.913984] RIP: 0010:mpihelp_submul_1+0x91/0xe0
[ 264.919460] RSP: 0018:ffffa36f44513940 EFLAGS: 00000206 ORIG_RAX: ffffffffffffffa2
[ 264.928565] RAX: 5414d8fd4127cc59 RBX: 0000000100000000 RCX: ffffffffffffff50
[ 264.936860] RDX: 00000000ffffffea RSI: 0000000019ba7e4d RDI: 0000000068ef6b86
[ 264.945146] RBP: ffffa36f44513960 R08: 352cbbd4573982a8 R09: 64589019128fea22
[ 264.953440] R10: 128fea2200000000 R11: 352cbbd5573982a8 R12: ffff89955c585c00
[ 264.961732] R13: ffff899134dbfbd0 R14: 66a4c31fb80cf128 R15: d7554d389539f6c8
[ 264.970028] </IRQ>
[ 264.972688] mpihelp_divrem+0x23b/0x740
[ 264.977291] mpi_powm+0x471/0xa10
[ 264.981312] rsa_verify+0xa5/0x130
[ 264.985421] pkcs1pad_verify+0xb9/0xf0
[ 264.989925] public_key_verify_signature+0x1f7/0x280
[ 264.995790] public_key_verify_signature_2+0x15/0x20
[ 265.001656] verify_signature+0x3c/0x50
[ 265.006259] pkcs7_validate_trust+0xa1/0x200
[ 265.011352] verify_pkcs7_signature+0x9a/0x140
[ 265.016636] mod_verify_sig+0x92/0xe0
[ 265.021046] load_module+0x171/0x2810
[ 265.025456] ? vfs_read+0x113/0x130
[ 265.029668] ? kernel_read_file+0x158/0x190
[ 265.034659] ? kernel_read_file_from_fd+0x49/0x80
[ 265.040248] SYSC_finit_module+0xa6/0xf0
[ 265.044947] SyS_finit_module+0xe/0x10
[ 265.049452] entry_SYSCALL_64_fastpath+0x1a/0xa9
[ 265.054931] RIP: 0033:0x7f74f2439239
[ 265.059241] RSP: 002b:00007ffeb8b23218 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 265.068373] RAX: ffffffffffffffda RBX: 00007ffeb8b21f10 RCX: 00007f74f2439239
[ 265.076665] RDX: 0000000000000000 RSI: 00005578b61d02a6 RDI: 0000000000000000
[ 265.084958] RBP: 00007ffeb8b21f00 R08: 0000000000000000 R09: 0000000000000000
[ 265.098996] R10: 0000000000000000 R11: 0000000000000246 R12: 00005578b61d1be7
[ 265.107289] R13: 00007ffeb8b22088 R14: 0000000000000000 R15: 00005578b61d1bf3
[ 265.115582] Code: 02 75 e2 48 8b 81 98 00 00 00 48 8b 91 a0 00 00 00 48 8b 7c 24 18 48 89 07 48 89 57 08 8b 81 84 00 00 00 85 c0 0f 85 86 00 00 00 <48> 8b 9c 24 20 01 00 00 65 48 33 1c 25 28 00 00 00 0f 85 a1 00
[ 265.143394] Kernel panic - not syncing: softlockup: hung tasks
[ 265.150231] CPU: 0 PID: 4867 Comm: modprobe Tainted: G L 4.9.0+ #27
[ 265.159057] Hardware name: Supermicro X9DRW/X9DRW, BIOS 3.0a 08/08/2013
[ 265.166766] Call Trace:
[ 265.169811] <IRQ>
[ 265.172374] dump_stack+0x63/0x8c
[ 265.176393] panic+0xeb/0x239
[ 265.180047] watchdog_timer_fn+0x1e5/0x1f0
[ 265.184941] ? watchdog+0x40/0x40
[ 265.188960] __hrtimer_run_queues+0xee/0x270
[ 265.194050] hrtimer_interrupt+0xa8/0x190
[ 265.198849] local_apic_timer_interrupt+0x35/0x60
[ 265.204422] smp_apic_timer_interrupt+0x38/0x50
[ 265.209802] apic_timer_interrupt+0x93/0xa0
[ 265.214794] RIP: 0010:fl_classify+0x1f1/0x2b0 [cls_flower]
[ 265.221242] RSP: 0018:ffff89916fa03ad8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
[ 265.230339] RAX: 00000000ffffffff RBX: ffff89913f522100 RCX: 0000000000000000
[ 265.238635] RDX: ffff89916fa03c98 RSI: ffff89915bd743c0 RDI: ffff89913f522100
[ 265.246929] RBP: ffff89916fa03c28 R08: 000000000000270f R09: 0000000000000000
[ 265.255223] R10: 0000000000000000 R11: 0000000000000004 R12: ffff89916fa03c98
[ 265.263516] R13: ffff89913ecc7c00 R14: ffff89915bd743c0 R15: 0000000000000001
[ 265.271812] ? handle_edge_irq+0x87/0x130
[ 265.276599] ? handle_irq+0xab/0x130
[ 265.280902] ? irq_exit+0x77/0xe0
[ 265.284911] ? irq_exit+0x77/0xe0
[ 265.288927] ? do_IRQ+0x51/0xd0
[ 265.292752] ? common_interrupt+0x93/0x93
[ 265.297549] tc_classify+0x78/0x120
[ 265.301762] __netif_receive_skb_core+0x623/0xa00
[ 265.307336] ? udp4_gro_receive+0x10b/0x2d0
[ 265.312328] __netif_receive_skb+0x18/0x60
[ 265.317221] netif_receive_skb_internal+0x40/0xb0
[ 265.322795] napi_gro_receive+0xcd/0x120
[ 265.327502] mlx5e_handle_rx_cqe_rep+0x61b/0x890 [mlx5_core]
[ 265.334153] ? kvm_irq_delivery_to_apic+0x2c0/0x2c0 [kvm]
[ 265.340510] mlx5e_poll_rx_cq+0x83/0x840 [mlx5_core]
[ 265.346379] mlx5e_napi_poll+0x89/0x480 [mlx5_core]
[ 265.352170] net_rx_action+0x260/0x3c0
[ 265.356675] __do_softirq+0xc9/0x28c
[ 265.360987] irq_exit+0xd7/0xe0
[ 265.364814] do_IRQ+0x51/0xd0
[ 265.368440] common_interrupt+0x93/0x93
[ 265.373041] RIP: 0010:mpihelp_submul_1+0x91/0xe0
[ 265.378516] RSP: 0018:ffffa36f44513940 EFLAGS: 00000206 ORIG_RAX: ffffffffffffffa2
[ 265.387614] RAX: 5414d8fd4127cc59 RBX: 0000000100000000 RCX: ffffffffffffff50
[ 265.395921] RDX: 00000000ffffffea RSI: 0000000019ba7e4d RDI: 0000000068ef6b86
[ 265.404235] RBP: ffffa36f44513960 R08: 352cbbd4573982a8 R09: 64589019128fea22
[ 265.412526] R10: 128fea2200000000 R11: 352cbbd5573982a8 R12: ffff89955c585c00
[ 265.420819] R13: ffff899134dbfbd0 R14: 66a4c31fb80cf128 R15: d7554d389539f6c8
[ 265.429113] </IRQ>
[ 265.431769] mpihelp_divrem+0x23b/0x740
[ 265.436373] mpi_powm+0x471/0xa10
[ 265.440394] rsa_verify+0xa5/0x130
[ 265.444508] pkcs1pad_verify+0xb9/0xf0
[ 265.449014] public_key_verify_signature+0x1f7/0x280
[ 265.454878] public_key_verify_signature_2+0x15/0x20
[ 265.460741] verify_signature+0x3c/0x50
[ 265.465343] pkcs7_validate_trust+0xa1/0x200
[ 265.470430] verify_pkcs7_signature+0x9a/0x140
[ 265.475715] mod_verify_sig+0x92/0xe0
[ 265.480147] load_module+0x171/0x2810
[ 265.484555] ? vfs_read+0x113/0x130
[ 265.488758] ? kernel_read_file+0x158/0x190
[ 265.493751] ? kernel_read_file_from_fd+0x49/0x80
[ 265.499328] SYSC_finit_module+0xa6/0xf0
[ 265.504051] SyS_finit_module+0xe/0x10
[ 265.508555] entry_SYSCALL_64_fastpath+0x1a/0xa9
[ 265.514030] RIP: 0033:0x7f74f2439239
[ 265.518340] RSP: 002b:00007ffeb8b23218 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 265.527446] RAX: ffffffffffffffda RBX: 00007ffeb8b21f10 RCX: 00007f74f2439239
[ 265.535740] RDX: 0000000000000000 RSI: 00005578b61d02a6 RDI: 0000000000000000
[ 265.544056] RBP: 00007ffeb8b21f00 R08: 0000000000000000 R09: 0000000000000000
[ 265.552354] R10: 0000000000000000 R11: 0000000000000246 R12: 00005578b61d1be7
[ 265.560648] R13: 00007ffeb8b22088 R14: 0000000000000000 R15: 00005578b61d1bf3
[ 265.568994] Kernel Offset: 0x3b000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 266.845267] ---[ end Kernel panic - not syncing: softlockup: hung tasks
[ 266.853000] ------------[ cut here ]------------
[ 266.858490] WARNING: CPU: 0 PID: 4867 at arch/x86/kernel/smp.c:127 native_smp_send_reschedule+0x3f/0x50
[ 266.869551] Modules linked in: act_gact act_mirred openvswitch nf_conntrack_ipv6 nf_nat_ipv6 nf_defrag_ipv6 vfio_pci vfio_virqfd vfio_iommu_type1 vfio cls_flower mlx5_ib mlx5_core devlink sch_ingress nfsv3 nfs fscache xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat libcrc32c nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun ebtable_filter ebtables ip6table_filter ip6_tables netconsole bridge stp llc rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm intel_rapl sb_edac edac_core x86_pkg_temp_thermal coretemp kvm_intel kvm ib_core irqbypass crct10dif_pclmul crc32_pclmul igb ptp iTCO_wdt pps_core crc32c_intel joydev i2c_algo_bit ghash_clmulni_intel iTCO_vendor_support pcspkr i2c_i801 mei_me ipmi_ssif ioatdma shpchp tpm_tis i2c_smbus tpm_tis_core dca tpm mei lpc_ich ipmi_si ipmi_msghandler wmi nfsd target_core_mod auth_rpcgss nfs_acl lockd grace sunrpc isci libsas serio_raw scsi_transport_sas [last unloaded: devlink]
[ 266.990566] CPU: 0 PID: 4867 Comm: modprobe Tainted: G L 4.9.0+ #27
[ 266.999401] Hardware name: Supermicro X9DRW/X9DRW, BIOS 3.0a 08/08/2013
[ 267.007118] Call Trace:
[ 267.010179] <IRQ>
[ 267.012748] dump_stack+0x63/0x8c
[ 267.016783] __warn+0xd1/0xf0
[ 267.020420] warn_slowpath_null+0x1d/0x20
[ 267.025314] native_smp_send_reschedule+0x3f/0x50
[ 267.030895] try_to_wake_up+0x312/0x390
[ 267.035501] wake_up_process+0x15/0x20
[ 267.040009] swake_up_locked+0x24/0x50
[ 267.044519] swake_up+0x2c/0x40
[ 267.048364] kvm_vcpu_kick+0x32/0x80 [kvm]
[ 267.053276] __apic_accept_irq+0x1b6/0x330 [kvm]
[ 267.058774] kvm_apic_set_irq+0x2a/0x30 [kvm]
[ 267.063978] kvm_irq_delivery_to_apic_fast+0xf5/0x3c0 [kvm]
[ 267.070544] kvm_arch_set_irq_inatomic+0x99/0xb0 [kvm]
[ 267.076621] irqfd_wakeup+0x111/0x160 [kvm]
[ 267.081628] ? kvm_irq_delivery_to_apic+0x2c0/0x2c0 [kvm]
[ 267.087984] __wake_up_common+0x55/0x90
[ 267.092583] __wake_up_locked_key+0x18/0x20
[ 267.097580] eventfd_signal+0x5c/0x80
[ 267.102001] vfio_msihandler+0x16/0x20 [vfio_pci]
[ 267.107578] __handle_irq_event_percpu+0x3c/0x1a0
[ 267.113164] handle_irq_event_percpu+0x32/0x80
[ 267.118453] handle_irq_event+0x2c/0x50
[ 267.123068] handle_edge_irq+0x87/0x130
[ 267.127677] handle_irq+0xab/0x130
[ 267.131801] do_IRQ+0x48/0xd0
[ 267.135435] common_interrupt+0x93/0x93
[ 267.140042] RIP: 0010:panic+0x1f5/0x239
[ 267.144647] RSP: 0018:ffff89916fa03898 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff73
[ 267.153760] RAX: 000000000000003b RBX: 0000000000000000 RCX: 0000000000000006
[ 267.162062] RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffff89916fa0e060
[ 267.170362] RBP: ffff89916fa03908 R08: 0000000000000691 R09: ffff898d000bc4c0
[ 267.178659] R10: 000000000000010a R11: 0000000000000198 R12: ffffffffbcc4a459
[ 267.186964] R13: 0000000000000000 R14: 0000000000000000 R15: ffff89916fa03a28
[ 267.195266] ? panic+0x1f1/0x239
[ 267.199201] watchdog_timer_fn+0x1e5/0x1f0
[ 267.204104] ? watchdog+0x40/0x40
[ 267.208130] __hrtimer_run_queues+0xee/0x270
[ 267.213224] hrtimer_interrupt+0xa8/0x190
[ 267.218036] local_apic_timer_interrupt+0x35/0x60
[ 267.223612] smp_apic_timer_interrupt+0x38/0x50
[ 267.228999] apic_timer_interrupt+0x93/0xa0
[ 267.233987] RIP: 0010:fl_classify+0x1f1/0x2b0 [cls_flower]
[ 267.240440] RSP: 0018:ffff89916fa03ad8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
[ 267.249539] RAX: 00000000ffffffff RBX: ffff89913f522100 RCX: 0000000000000000
[ 267.257829] RDX: ffff89916fa03c98 RSI: ffff89915bd743c0 RDI: ffff89913f522100
[ 267.266128] RBP: ffff89916fa03c28 R08: 000000000000270f R09: 0000000000000000
[ 267.274425] R10: 0000000000000000 R11: 0000000000000004 R12: ffff89916fa03c98
[ 267.282721] R13: ffff89913ecc7c00 R14: ffff89915bd743c0 R15: 0000000000000001
[ 267.291019] ? handle_edge_irq+0x87/0x130
[ 267.295818] ? handle_irq+0xab/0x130
[ 267.300133] ? irq_exit+0x77/0xe0
[ 267.304160] ? irq_exit+0x77/0xe0
[ 267.308184] ? do_IRQ+0x51/0xd0
[ 267.312015] ? common_interrupt+0x93/0x93
[ 267.316818] tc_classify+0x78/0x120
[ 267.321038] __netif_receive_skb_core+0x623/0xa00
[ 267.326618] ? udp4_gro_receive+0x10b/0x2d0
[ 267.331616] __netif_receive_skb+0x18/0x60
[ 267.336514] netif_receive_skb_internal+0x40/0xb0
[ 267.342091] napi_gro_receive+0xcd/0x120
[ 267.346809] mlx5e_handle_rx_cqe_rep+0x61b/0x890 [mlx5_core]
[ 267.353467] ? kvm_irq_delivery_to_apic+0x2c0/0x2c0 [kvm]
[ 267.359837] mlx5e_poll_rx_cq+0x83/0x840 [mlx5_core]
[ 267.365716] mlx5e_napi_poll+0x89/0x480 [mlx5_core]
[ 267.371500] net_rx_action+0x260/0x3c0
[ 267.376008] __do_softirq+0xc9/0x28c
[ 267.380330] irq_exit+0xd7/0xe0
[ 267.384168] do_IRQ+0x51/0xd0
[ 267.387810] common_interrupt+0x93/0x93
[ 267.392426] RIP: 0010:mpihelp_submul_1+0x91/0xe0
[ 267.403605] RSP: 0018:ffffa36f44513940 EFLAGS: 00000206 ORIG_RAX: ffffffffffffffa2
[ 267.412818] RAX: 5414d8fd4127cc59 RBX: 0000000100000000 RCX: ffffffffffffff50
[ 267.421114] RDX: 00000000ffffffea RSI: 0000000019ba7e4d RDI: 0000000068ef6b86
[ 267.429418] RBP: ffffa36f44513960 R08: 352cbbd4573982a8 R09: 64589019128fea22
[ 267.437713] R10: 128fea2200000000 R11: 352cbbd5573982a8 R12: ffff89955c585c00
[ 267.446014] R13: ffff899134dbfbd0 R14: 66a4c31fb80cf128 R15: d7554d389539f6c8
[ 267.454311] </IRQ>
[ 267.456981] mpihelp_divrem+0x23b/0x740
[ 267.461598] mpi_powm+0x471/0xa10
[ 267.465630] rsa_verify+0xa5/0x130
[ 267.469759] pkcs1pad_verify+0xb9/0xf0
[ 267.474277] public_key_verify_signature+0x1f7/0x280
[ 267.480148] public_key_verify_signature_2+0x15/0x20
[ 267.486011] verify_signature+0x3c/0x50
[ 267.490619] pkcs7_validate_trust+0xa1/0x200
[ 267.495710] verify_pkcs7_signature+0x9a/0x140
[ 267.501000] mod_verify_sig+0x92/0xe0
[ 267.505404] load_module+0x171/0x2810
[ 267.509822] ? vfs_read+0x113/0x130
[ 267.514047] ? kernel_read_file+0x158/0x190
[ 267.519041] ? kernel_read_file_from_fd+0x49/0x80
[ 267.524620] SYSC_finit_module+0xa6/0xf0
[ 267.529325] SyS_finit_module+0xe/0x10
[ 267.533844] entry_SYSCALL_64_fastpath+0x1a/0xa9
[ 267.539325] RIP: 0033:0x7f74f2439239
[ 267.543639] RSP: 002b:00007ffeb8b23218 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 267.552740] RAX: ffffffffffffffda RBX: 00007ffeb8b21f10 RCX: 00007f74f2439239
[ 267.561042] RDX: 0000000000000000 RSI: 00005578b61d02a6 RDI: 0000000000000000
[ 267.569341] RBP: 00007ffeb8b21f00 R08: 0000000000000000 R09: 0000000000000000
[ 267.577638] R10: 0000000000000000 R11: 0000000000000246 R12: 00005578b61d1be7
[ 267.585935] R13: 00007ffeb8b22088 R14: 0000000000000000 R15: 00005578b61d1bf3
[ 267.594231] ---[ end trace 2eb46a584b6ba420 ]---
^ permalink raw reply
* Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: Jean-Philippe Aumasson @ 2016-12-19 20:18 UTC (permalink / raw)
To: George Spelvin, David.Laight, tom
Cc: ak, davem, djb, ebiggers3, hannes, Jason, kernel-hardening,
linux-crypto, linux-kernel, luto, netdev, torvalds, tytso,
vegard.nossum
In-Reply-To: <20161219181040.25441.qmail@ns.sciencehorizons.net>
[-- Attachment #1: Type: text/plain, Size: 3984 bytes --]
FTR, I agree that SipHash may benefit from security/performance
optimizations (there's always optimizations), but I'm note sure that it's
the right time/place to discuss it. Cryptanalysis is hard, and any major
change should be backed by a rigorous security analysis and/or security
proof. For example, the redundancy in the initial state prevents trivial
weaknesses that would occur if four key words were used (something I've
seen proposed in this thread).
In the paper at http://aumasson.jp/siphash/siphash.pdf we explain rationale
behind most of our design choices. The cryptanalysis paper at
https://eprint.iacr.org/2014/722.pdf analyzes differences propagations and
presents attacks on reduced versions of SipHash.
On Mon, Dec 19, 2016 at 7:10 PM George Spelvin <linux@sciencehorizons.net>
wrote:
> David Laight wrote:
> > From: George Spelvin
> ...
> >> uint32_t
> >> hsiphash24(char const *in, size_t len, uint32_t const key[2])
> >> {
> >> uint32_t c = key[0];
> >> uint32_t d = key[1];
> >> uint32_t a = 0x6c796765 ^ 0x736f6d65;
> >> uint32_t b = d ^ 0x74656462 ^ 0x646f7261;
>
> > I've not looked closely, but is that (in some sense) duplicating
> > the key length?
> > So you could set a = key[2] and b = key[3] and still have an
> > working hash - albeit not exactly the one specified.
>
> That's tempting, but not necessarily effective. (A similar unsuccesful
> idea can be found in discussions of "DES with independent round keys".
> Or see the design discussion of Salsa20 and the constants in its input.)
>
> You can increase the key size, but that might not increase the *security*
> any.
>
> The big issue is that there are a *lot* of square root attack in
> cryptanalysis. Because SipHash's state is twice the size of the key,
> such an attack will have the same complexity as key exhaustion and need
> not be considered. To make a stronger security claim, you need to start
> working through them all and show that they don't apply.
>
> For SipHash in particular, an important property is asymmetry of the
> internal state. That's what duplicating the key with XORs guarantees.
> If the two halves of the state end up identical, the mixing is much
> weaker.
>
> Now the probability of ending up in a "mirror state" is the square
> root of the state size (1 in 2^64 for HalfSipHash's 128-bit state),
> which is the same probability as guessing a key, so it's not a
> problem that has to be considered when making a 64-bit security claim.
>
> But if you want a higher security level, you have to think about
> what can happen.
>
> That said, I have been thinking very hard about
>
> a = c ^ 0x48536970; /* 'HSip' */
> d = key[2];
>
> By guaranteeing that a and c are different, we get the desired
> asymmetry, and the XOR of b and d is determined by the first word of
> the message anyway, so this isn't weakening anything.
>
> 96 bits is far beyond the reach of any brute-force attack, and if a
> more sophisticated 64-bit attack exists, it's at least out of the reach
> of the script kiddies, and will almost certainly have a non-negligible
> constant factor and more limits in when it can be applied.
>
> > Is it worth using the 32bit hash for IP addresses on 64bit systems that
> > can't do misaligned accessed?
>
> Not a good idea. To hash 64 bits of input:
>
> * Full SipHash has to do two loads, a shift, an or, and two rounds of
> mixing.
> * HalfSipHash has to do a load, two rounds, another load, and two more
> rounds.
>
> In other words, in addition to being less secure, it's half the speed.
>
> Also, what systems are you thinking about? x86, ARMv8, PowerPC, and
> S390 (and ia64, if anyone cares) all handle unaligned loads. MIPS has
> efficient support. Alpha and HPPA are for retrocomputing fans, not
> people who care about performance.
>
> So you're down to SPARC. Which conveniently has the same maintainer as
> the networking code, so I figure DaveM can take care of that himself. :-)
>
[-- Attachment #2: Type: text/html, Size: 6131 bytes --]
^ permalink raw reply
* Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff
From: Julian Anastasov @ 2016-12-19 20:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-sctp, YueHaibing
In-Reply-To: <1482164252.1521.7.camel@edumazet-glaptop3.roam.corp.google.com>
Hello,
On Mon, 19 Dec 2016, Eric Dumazet wrote:
> I am still digesting this awesome patch series ;)
Thanks. I don't feel quite comfortable with some
of the changes (mostly XFRM, dst_confirm usage in CXGB) and
I hope the discussion can provide adequate solution.
> Not sure why you used an unlikely() here. TCP for example would hit this
> path quite often.
I was not sure, may be because ACKs can come with lower
rate than the sent packets. Also because non-TCP rarely uses
MSG_CONFIRM. If you still think it is better without unlikely,
I'll remove it.
> So considering sk_dst_pending_confirm might be dirtied quite often,
>
> I am not sure why you placed it in the cache line that contains
> sk_rx_dst (in 1st patch)
I saw your recent changes and was worried if the
sk_dst_confirm() calling on RX can cause unwanted dirtying of
additional cache line. My preliminary analyze pointed
sk_omem_alloc as good candidate for moving to next cache
line. I know how critical is to properly place the new flags,
so I really need recommendations about this.
Regards
^ permalink raw reply
* [PATCH net v4 1/4] fsl/fman: fix 1G support for QSGMII interfaces
From: Madalin Bucur @ 2016-12-19 20:42 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482180166-10677-1-git-send-email-madalin.bucur@nxp.com>
QSGMII ports were not advertising 1G speed.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
---
drivers/net/ethernet/freescale/fman/mac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/fman/mac.c b/drivers/net/ethernet/freescale/fman/mac.c
index 69ca42c..0b31f85 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -594,6 +594,7 @@ static const u16 phy2speed[] = {
[PHY_INTERFACE_MODE_RGMII_RXID] = SPEED_1000,
[PHY_INTERFACE_MODE_RGMII_TXID] = SPEED_1000,
[PHY_INTERFACE_MODE_RTBI] = SPEED_1000,
+ [PHY_INTERFACE_MODE_QSGMII] = SPEED_1000,
[PHY_INTERFACE_MODE_XGMII] = SPEED_10000
};
--
2.1.0
^ permalink raw reply related
* [PATCH net v4 2/4] powerpc: fsl/fman: remove fsl,fman from of_device_ids[]
From: Madalin Bucur @ 2016-12-19 20:42 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482180166-10677-1-git-send-email-madalin.bucur@nxp.com>
The fsl/fman drivers will use of_platform_populate() on all
supported platforms. Call of_platform_populate() to probe the
FMan sub-nodes.
Signed-off-by: Igal Liberman <igal.liberman@freescale.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Acked-by: Scott Wood <oss@buserror.net>
---
arch/powerpc/platforms/85xx/corenet_generic.c | 3 ---
drivers/net/ethernet/freescale/fman/fman.c | 7 +++++++
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index 1179115..824b7f1 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -117,9 +117,6 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = "fsl,qe",
},
- {
- .compatible = "fsl,fman",
- },
/* The following two are for the Freescale hypervisor */
{
.name = "hypervisor",
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index dafd9e1..4b83263 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2868,6 +2868,13 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
fman->dev = &of_dev->dev;
+ err = of_platform_populate(fm_node, NULL, NULL, &of_dev->dev);
+ if (err) {
+ dev_err(&of_dev->dev, "%s: of_platform_populate() failed\n",
+ __func__);
+ goto fman_free;
+ }
+
return fman;
fman_node_put:
--
2.1.0
^ permalink raw reply related
* [PATCH net v4 4/4] fsl/fman: enable compilation on ARM64
From: Madalin Bucur @ 2016-12-19 20:42 UTC (permalink / raw)
To: netdev; +Cc: scott.wood, linuxppc-dev, linux-kernel, davem
In-Reply-To: <1482180166-10677-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/net/ethernet/freescale/fman/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fman/Kconfig b/drivers/net/ethernet/freescale/fman/Kconfig
index 79b7c84..dc0850b 100644
--- a/drivers/net/ethernet/freescale/fman/Kconfig
+++ b/drivers/net/ethernet/freescale/fman/Kconfig
@@ -1,6 +1,6 @@
config FSL_FMAN
tristate "FMan support"
- depends on FSL_SOC || COMPILE_TEST
+ depends on FSL_SOC || ARCH_LAYERSCAPE || COMPILE_TEST
select GENERIC_ALLOCATOR
select PHYLIB
default n
--
2.1.0
^ permalink raw reply related
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