* Re: [PATCH net v2] mlx4: Return EOPNOTSUPP instead of ENOTSUPP
From: Martin KaFai Lau @ 2017-01-10 22:36 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Linux Netdev List, Saeed Mahameed, Tariq Toukan, Kernel Team
In-Reply-To: <CALzJLG99semMYGKMO1QvNg1EK0m-uFWv4+-o45oV9t3QoY6_rw@mail.gmail.com>
On Tue, Jan 10, 2017 at 10:04:55PM +0200, Saeed Mahameed wrote:
> On Tue, Jan 10, 2017 at 7:41 PM, Martin KaFai Lau <kafai@fb.com> wrote:
> > In commit b45f0674b997 ("mlx4: xdp: Allow raising MTU up to one page minus eth and vlan hdrs"),
> > it changed EOPNOTSUPP to ENOTSUPP by mistake. This patch fixes it.
> >
> > Fixes: b45f0674b997 ("mlx4: xdp: Allow raising MTU up to one page minus eth and vlan hdrs")
> > Signed-off-by: Martin KaFai Lau <kafai@fb.com>
>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
>
>
> Thank you martin.
>
> Small question though,
> is it essential for the upper layer to get the correct errno ? or this
> is just a cleanup ?
Former. probably for the netlink's NLMSG_ERROR also.
^ permalink raw reply
* [PATCH net] net: ipv4: Fix multipath selection with vrf
From: David Ahern @ 2017-01-10 22:37 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
fib_select_path does not call fib_select_multipath if oif is set in the
flow struct. For VRF use cases oif is always set, so multipath route
selection is bypassed. Use the FLOWI_FLAG_SKIP_NH_OIF to skip the oif
check similar to what is done in fib_table_lookup.
Add saddr and proto to the flow struct for the fib lookup done by the
VRF driver to better match hash computation for a flow.
Fixes: 613d09b30f8b ("net: Use VRF device index for lookups on TX")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
IPv6 multipath selection works fine as is.
drivers/net/vrf.c | 2 ++
net/ipv4/fib_semantics.c | 9 +++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 23dfb0eac098..0a067708aa39 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -263,7 +263,9 @@ static netdev_tx_t vrf_process_v4_outbound(struct sk_buff *skb,
.flowi4_iif = LOOPBACK_IFINDEX,
.flowi4_tos = RT_TOS(ip4h->tos),
.flowi4_flags = FLOWI_FLAG_ANYSRC | FLOWI_FLAG_SKIP_NH_OIF,
+ .flowi4_proto = ip4h->protocol,
.daddr = ip4h->daddr,
+ .saddr = ip4h->saddr,
};
struct net *net = dev_net(vrf_dev);
struct rtable *rt;
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 7a5b4c7d9a87..eba1546b5031 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1618,8 +1618,13 @@ void fib_select_multipath(struct fib_result *res, int hash)
void fib_select_path(struct net *net, struct fib_result *res,
struct flowi4 *fl4, int mp_hash)
{
+ bool oif_check;
+
+ oif_check = (fl4->flowi4_oif == 0 ||
+ fl4->flowi4_flags & FLOWI_FLAG_SKIP_NH_OIF);
+
#ifdef CONFIG_IP_ROUTE_MULTIPATH
- if (res->fi->fib_nhs > 1 && fl4->flowi4_oif == 0) {
+ if (res->fi->fib_nhs > 1 && oif_check) {
if (mp_hash < 0)
mp_hash = get_hash_from_flowi4(fl4) >> 1;
@@ -1629,7 +1634,7 @@ void fib_select_path(struct net *net, struct fib_result *res,
#endif
if (!res->prefixlen &&
res->table->tb_num_default > 1 &&
- res->type == RTN_UNICAST && !fl4->flowi4_oif)
+ res->type == RTN_UNICAST && oif_check)
fib_select_default(fl4, res);
if (!fl4->saddr)
--
2.1.4
^ permalink raw reply related
* Re: net/atm: warning in alloc_tx/__might_sleep
From: Francois Romieu @ 2017-01-10 22:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: Cong Wang, Andrey Konovalov, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML,
Al Viro, Dmitry Vyukov, Kostya Serebryany, syzkaller
In-Reply-To: <CANn89iLxQPAt0e5Yc0yYFFQtoQwuRsdAwH9m1d4oqWQ3W=DZTQ@mail.gmail.com>
Eric Dumazet <edumazet@google.com> :
> On Tue, Jan 10, 2017 at 9:35 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > On Mon, Jan 9, 2017 at 9:20 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >
> > The fix should be straight-forward. Mind to try the attached patch?
>
>
> You forgot to remove schedule() ?
It may be clearer to split alloc_tx in two parts: only the unsleepable
"if (sk_wmem_alloc_get(sk) && !atm_may_send(vcc, size)) {" part of it
contributes to the inner "while (!(skb = alloc_tx(vcc, eff))) {" block.
See net/atm/common.c
[...]
static struct sk_buff *alloc_tx(struct atm_vcc *vcc, unsigned int size)
{
struct sk_buff *skb;
struct sock *sk = sk_atm(vcc);
if (sk_wmem_alloc_get(sk) && !atm_may_send(vcc, size)) {
pr_debug("Sorry: wmem_alloc = %d, size = %d, sndbuf = %d\n",
sk_wmem_alloc_get(sk), size, sk->sk_sndbuf);
return NULL;
}
while (!(skb = alloc_skb(size, GFP_KERNEL)))
schedule();
pr_debug("%d += %d\n", sk_wmem_alloc_get(sk), skb->truesize);
atomic_add(skb->truesize, &sk->sk_wmem_alloc);
return skb;
}
The waiting stuff is related to vcc drain but the code makes it look as
if it were also related to skb alloc (it isn't).
It may be obvious for you but it took me a while to figure what the
code is supposed to achieve.
--
Ueimor
^ permalink raw reply
* [PATCH] sctp: Fix spelling mistake: "Atempt" -> "Attempt"
From: Colin King @ 2017-01-10 22:53 UTC (permalink / raw)
To: Vlad Yasevich, Neil Horman, David S . Miller, linux-sctp, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in WARN_ONCE message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/sctp/outqueue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index e540826..34efaa4 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -1048,7 +1048,7 @@ static void sctp_outq_flush(struct sctp_outq *q, int rtx_timeout, gfp_t gfp)
(new_transport->state == SCTP_PF)))
new_transport = asoc->peer.active_path;
if (new_transport->state == SCTP_UNCONFIRMED) {
- WARN_ONCE(1, "Atempt to send packet on unconfirmed path.");
+ WARN_ONCE(1, "Attempt to send packet on unconfirmed path.");
sctp_chunk_fail(chunk, 0);
sctp_chunk_free(chunk);
continue;
--
2.10.2
^ permalink raw reply related
* [PATCH] net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
From: Russell King @ 2017-01-10 23:13 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Charles-Antoine Couret, linux-arm-kernel, netdev
When an Marvell 88E1512 PHY is connected to a nic in SGMII mode, the
fiber page is used for the SGMII host-side connection. The PHY driver
notices that SUPPORTED_FIBRE is set, so it tries reading the fiber page
for the link status, and ends up reading the MAC-side status instead of
the outgoing (copper) link. This leads to incorrect results reported
via ethtool.
If the PHY is connected via SGMII to the host, ignore the fiber page.
However, continue to allow the existing power management code to
suspend and resume the fiber page.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/marvell.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 6ad76829c7cd..04e439ad5cff 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1190,7 +1190,8 @@ static int marvell_read_status(struct phy_device *phydev)
int err;
/* Check the fiber mode first */
- if (phydev->supported & SUPPORTED_FIBRE) {
+ if (phydev->supported & SUPPORTED_FIBRE &&
+ phydev->interface != PHY_INTERFACE_MODE_SGMII) {
err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_FIBER);
if (err < 0)
goto error;
--
2.7.4
^ permalink raw reply related
* [PATCH] net: vrf: do not allow table id 0
From: David Ahern @ 2017-01-10 23:22 UTC (permalink / raw)
To: netdev; +Cc: frank.kellermann, David Ahern
Frank reported that vrf devices can be created with a table id of 0.
This breaks many of the run time table id checks and should not be
allowed. Detect this condition at create time and fail with EINVAL.
Fixes: 193125dbd8eb ("net: Introduce VRF device driver")
Reported-by: Frank Kellermann <frank.kellermann@atos.net>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
drivers/net/vrf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index 0a067708aa39..454f907d419a 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -1252,6 +1252,8 @@ static int vrf_newlink(struct net *src_net, struct net_device *dev,
return -EINVAL;
vrf->tb_id = nla_get_u32(data[IFLA_VRF_TABLE]);
+ if (vrf->tb_id == RT_TABLE_UNSPEC)
+ return -EINVAL;
dev->priv_flags |= IFF_L3MDEV_MASTER;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
From: Florian Fainelli @ 2017-01-10 23:24 UTC (permalink / raw)
To: Russell King
Cc: Andrew Lunn, Charles-Antoine Couret, linux-arm-kernel, netdev
In-Reply-To: <E1cR5bt-0000O8-1T@rmk-PC.armlinux.org.uk>
On 01/10/2017 03:13 PM, Russell King wrote:
> When an Marvell 88E1512 PHY is connected to a nic in SGMII mode, the
> fiber page is used for the SGMII host-side connection. The PHY driver
> notices that SUPPORTED_FIBRE is set, so it tries reading the fiber page
> for the link status, and ends up reading the MAC-side status instead of
> the outgoing (copper) link. This leads to incorrect results reported
> via ethtool.
>
> If the PHY is connected via SGMII to the host, ignore the fiber page.
> However, continue to allow the existing power management code to
> suspend and resume the fiber page.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Fixes: 6cfb3bcc0641 ("Marvell phy: check link status in case of fiber
link.")
--
Florian
^ permalink raw reply
* [PATCH v2 0/8] Switch BPF's digest to SHA256
From: Andy Lutomirski @ 2017-01-10 23:24 UTC (permalink / raw)
To: Daniel Borkmann, Netdev, LKML, Linux Crypto Mailing List
Cc: Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Andy Lutomirski
I can imagine future uses for the new-in-4.10 BPF digest feature that
would be problematic if malicious users could produce collisions, and
SHA-1 is no longer consdiered to be collision-free. Even without
needing collision resistance, SHA-1 is no longer recommended for new
applications. Switch the BPF digest to SHA-256 instead.
The actual switchover is trivial. Most of this series consists of
cleanups to the SHA256 code to make it usable as a standalone library
(since BPF should not depend on crypto).
The cleaned up library is much more user-friendly than the SHA-1 code,
so this also significantly tidies up the BPF digest code.
This is intended for 4.10. If this series misses 4.10 and nothing
takes its place, then we'll have an unpleasant ABI stability
situation.
NB: I would be happy to make parallel changes to the SHA-512 code if
the crypto folks would like for me to do so. I haven't yet because I
wanted to minimize churn. Also, the changes will be essentially
identical to the SHA-256 changes and I want to get the latter
reviewed first.
Andy Lutomirski (8):
crypto/sha256: Factor out the parts of base API that don't use
shash_desc
crypto/sha256: Export a sha256_{init,update,final}_direct() API
crypto/sha256: Build the SHA256 core separately from the crypto module
bpf: Use SHA256 instead of SHA1 for bpf digests
bpf: Avoid copying the entire BPF program when hashing it
bpf: Rename fdinfo's prog_digest to prog_sha256
net: Rename TCA*BPF_DIGEST to ..._SHA256
crypto/testmgr: Allocate only the required output size for hash tests
crypto/Kconfig | 8 ++
crypto/Makefile | 1 +
crypto/sha256_direct.c | 238 +++++++++++++++++++++++++++++++++++++
crypto/sha256_generic.c | 215 ++-------------------------------
crypto/testmgr.c | 9 +-
include/crypto/sha.h | 24 ++++
include/crypto/sha256_base.h | 58 +++++----
include/linux/filter.h | 11 +-
include/uapi/linux/pkt_cls.h | 2 +-
include/uapi/linux/tc_act/tc_bpf.h | 2 +-
init/Kconfig | 1 +
kernel/bpf/core.c | 63 +++-------
kernel/bpf/syscall.c | 2 +-
net/sched/act_bpf.c | 2 +-
net/sched/cls_bpf.c | 2 +-
15 files changed, 343 insertions(+), 295 deletions(-)
create mode 100644 crypto/sha256_direct.c
--
2.9.3
^ permalink raw reply
* [PATCH v2 1/8] crypto/sha256: Factor out the parts of base API that don't use shash_desc
From: Andy Lutomirski @ 2017-01-10 23:24 UTC (permalink / raw)
To: Daniel Borkmann, Netdev, LKML, Linux Crypto Mailing List
Cc: Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Andy Lutomirski, Ard Biesheuvel, Herbert Xu
In-Reply-To: <cover.1484090585.git.luto@kernel.org>
I want to expose a minimal SHA256 API that can be used without the
depending on the crypto core. To prepare for this, factor out the
meat of the sha256_base_*() helpers.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
include/crypto/sha256_base.h | 53 ++++++++++++++++++++++++++++++--------------
1 file changed, 36 insertions(+), 17 deletions(-)
diff --git a/include/crypto/sha256_base.h b/include/crypto/sha256_base.h
index d1f2195bb7de..fc77b8e099a7 100644
--- a/include/crypto/sha256_base.h
+++ b/include/crypto/sha256_base.h
@@ -18,10 +18,8 @@
typedef void (sha256_block_fn)(struct sha256_state *sst, u8 const *src,
int blocks);
-static inline int sha224_base_init(struct shash_desc *desc)
+static inline void sha224_init_direct(struct sha256_state *sctx)
{
- struct sha256_state *sctx = shash_desc_ctx(desc);
-
sctx->state[0] = SHA224_H0;
sctx->state[1] = SHA224_H1;
sctx->state[2] = SHA224_H2;
@@ -31,14 +29,16 @@ static inline int sha224_base_init(struct shash_desc *desc)
sctx->state[6] = SHA224_H6;
sctx->state[7] = SHA224_H7;
sctx->count = 0;
+}
+static inline int sha224_base_init(struct shash_desc *desc)
+{
+ sha224_init_direct(shash_desc_ctx(desc));
return 0;
}
-static inline int sha256_base_init(struct shash_desc *desc)
+static inline void sha256_init_direct(struct sha256_state *sctx)
{
- struct sha256_state *sctx = shash_desc_ctx(desc);
-
sctx->state[0] = SHA256_H0;
sctx->state[1] = SHA256_H1;
sctx->state[2] = SHA256_H2;
@@ -48,16 +48,19 @@ static inline int sha256_base_init(struct shash_desc *desc)
sctx->state[6] = SHA256_H6;
sctx->state[7] = SHA256_H7;
sctx->count = 0;
+}
+static inline int sha256_base_init(struct shash_desc *desc)
+{
+ sha256_init_direct(shash_desc_ctx(desc));
return 0;
}
-static inline int sha256_base_do_update(struct shash_desc *desc,
- const u8 *data,
- unsigned int len,
- sha256_block_fn *block_fn)
+static inline void __sha256_base_do_update(struct sha256_state *sctx,
+ const u8 *data,
+ unsigned int len,
+ sha256_block_fn *block_fn)
{
- struct sha256_state *sctx = shash_desc_ctx(desc);
unsigned int partial = sctx->count % SHA256_BLOCK_SIZE;
sctx->count += len;
@@ -86,15 +89,21 @@ static inline int sha256_base_do_update(struct shash_desc *desc,
}
if (len)
memcpy(sctx->buf + partial, data, len);
+}
+static inline int sha256_base_do_update(struct shash_desc *desc,
+ const u8 *data,
+ unsigned int len,
+ sha256_block_fn *block_fn)
+{
+ __sha256_base_do_update(shash_desc_ctx(desc), data, len, block_fn);
return 0;
}
-static inline int sha256_base_do_finalize(struct shash_desc *desc,
- sha256_block_fn *block_fn)
+static inline void sha256_do_finalize_direct(struct sha256_state *sctx,
+ sha256_block_fn *block_fn)
{
const int bit_offset = SHA256_BLOCK_SIZE - sizeof(__be64);
- struct sha256_state *sctx = shash_desc_ctx(desc);
__be64 *bits = (__be64 *)(sctx->buf + bit_offset);
unsigned int partial = sctx->count % SHA256_BLOCK_SIZE;
@@ -109,14 +118,18 @@ static inline int sha256_base_do_finalize(struct shash_desc *desc,
memset(sctx->buf + partial, 0x0, bit_offset - partial);
*bits = cpu_to_be64(sctx->count << 3);
block_fn(sctx, sctx->buf, 1);
+}
+static inline int sha256_base_do_finalize(struct shash_desc *desc,
+ sha256_block_fn *block_fn)
+{
+ sha256_do_finalize_direct(shash_desc_ctx(desc), block_fn);
return 0;
}
-static inline int sha256_base_finish(struct shash_desc *desc, u8 *out)
+static inline void __sha256_base_finish(struct sha256_state *sctx,
+ unsigned int digest_size, u8 *out)
{
- unsigned int digest_size = crypto_shash_digestsize(desc->tfm);
- struct sha256_state *sctx = shash_desc_ctx(desc);
__be32 *digest = (__be32 *)out;
int i;
@@ -124,5 +137,11 @@ static inline int sha256_base_finish(struct shash_desc *desc, u8 *out)
put_unaligned_be32(sctx->state[i], digest++);
*sctx = (struct sha256_state){};
+}
+
+static inline int sha256_base_finish(struct shash_desc *desc, u8 *out)
+{
+ __sha256_base_finish(shash_desc_ctx(desc),
+ crypto_shash_digestsize(desc->tfm), out);
return 0;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/8] crypto/sha256: Export a sha256_{init,update,final}_direct() API
From: Andy Lutomirski @ 2017-01-10 23:24 UTC (permalink / raw)
To: Daniel Borkmann, Netdev, LKML, Linux Crypto Mailing List
Cc: Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Andy Lutomirski, Ard Biesheuvel, Herbert Xu
In-Reply-To: <cover.1484090585.git.luto@kernel.org>
This provides a very simple interface for kernel code to use to do
synchronous, unaccelerated, virtual-address-based SHA256 hashing
without needing to create a crypto context.
Subsequent patches will make this work without building the crypto
core and will use to avoid making BPF-based tracing depend on
crypto.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
crypto/sha256_generic.c | 31 ++++++++++++++++++++++++++-----
include/crypto/sha.h | 24 ++++++++++++++++++++++++
include/crypto/sha256_base.h | 13 -------------
3 files changed, 50 insertions(+), 18 deletions(-)
diff --git a/crypto/sha256_generic.c b/crypto/sha256_generic.c
index 8f9c47e1a96e..573e114382f9 100644
--- a/crypto/sha256_generic.c
+++ b/crypto/sha256_generic.c
@@ -240,24 +240,45 @@ static void sha256_generic_block_fn(struct sha256_state *sst, u8 const *src,
}
}
+void sha256_update_direct(struct sha256_state *sctx, const u8 *data,
+ unsigned int len)
+{
+ __sha256_base_do_update(sctx, data, len, sha256_generic_block_fn);
+}
+EXPORT_SYMBOL(sha256_update_direct);
+
int crypto_sha256_update(struct shash_desc *desc, const u8 *data,
unsigned int len)
{
- return sha256_base_do_update(desc, data, len, sha256_generic_block_fn);
+ sha256_update_direct(shash_desc_ctx(desc), data, len);
+ return 0;
}
EXPORT_SYMBOL(crypto_sha256_update);
static int sha256_final(struct shash_desc *desc, u8 *out)
{
- sha256_base_do_finalize(desc, sha256_generic_block_fn);
- return sha256_base_finish(desc, out);
+ __sha256_final_direct(shash_desc_ctx(desc),
+ crypto_shash_digestsize(desc->tfm), out);
+ return 0;
}
+void __sha256_final_direct(struct sha256_state *sctx, unsigned int digest_size,
+ u8 *out)
+{
+ sha256_do_finalize_direct(sctx, sha256_generic_block_fn);
+ __sha256_base_finish(sctx, digest_size, out);
+}
+EXPORT_SYMBOL(sha256_final_direct);
+
int crypto_sha256_finup(struct shash_desc *desc, const u8 *data,
unsigned int len, u8 *hash)
{
- sha256_base_do_update(desc, data, len, sha256_generic_block_fn);
- return sha256_final(desc, hash);
+ struct sha256_state *sctx = shash_desc_ctx(desc);
+ unsigned int digest_size = crypto_shash_digestsize(desc->tfm);
+
+ sha256_update_direct(sctx, data, len);
+ __sha256_final_direct(sctx, digest_size, hash);
+ return 0;
}
EXPORT_SYMBOL(crypto_sha256_finup);
diff --git a/include/crypto/sha.h b/include/crypto/sha.h
index c94d3eb1cefd..0df1a0e42c95 100644
--- a/include/crypto/sha.h
+++ b/include/crypto/sha.h
@@ -88,6 +88,30 @@ struct sha512_state {
u8 buf[SHA512_BLOCK_SIZE];
};
+static inline void sha256_init_direct(struct sha256_state *sctx)
+{
+ sctx->state[0] = SHA256_H0;
+ sctx->state[1] = SHA256_H1;
+ sctx->state[2] = SHA256_H2;
+ sctx->state[3] = SHA256_H3;
+ sctx->state[4] = SHA256_H4;
+ sctx->state[5] = SHA256_H5;
+ sctx->state[6] = SHA256_H6;
+ sctx->state[7] = SHA256_H7;
+ sctx->count = 0;
+}
+
+extern void sha256_update_direct(struct sha256_state *sctx, const u8 *data,
+ unsigned int len);
+
+extern void __sha256_final_direct(struct sha256_state *sctx,
+ unsigned int digest_size, u8 *out);
+
+static inline void sha256_final_direct(struct sha256_state *sctx, u8 *out)
+{
+ __sha256_final_direct(sctx, SHA256_DIGEST_SIZE, out);
+}
+
struct shash_desc;
extern int crypto_sha1_update(struct shash_desc *desc, const u8 *data,
diff --git a/include/crypto/sha256_base.h b/include/crypto/sha256_base.h
index fc77b8e099a7..9bbe73ce458f 100644
--- a/include/crypto/sha256_base.h
+++ b/include/crypto/sha256_base.h
@@ -37,19 +37,6 @@ static inline int sha224_base_init(struct shash_desc *desc)
return 0;
}
-static inline void sha256_init_direct(struct sha256_state *sctx)
-{
- sctx->state[0] = SHA256_H0;
- sctx->state[1] = SHA256_H1;
- sctx->state[2] = SHA256_H2;
- sctx->state[3] = SHA256_H3;
- sctx->state[4] = SHA256_H4;
- sctx->state[5] = SHA256_H5;
- sctx->state[6] = SHA256_H6;
- sctx->state[7] = SHA256_H7;
- sctx->count = 0;
-}
-
static inline int sha256_base_init(struct shash_desc *desc)
{
sha256_init_direct(shash_desc_ctx(desc));
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/8] crypto/sha256: Build the SHA256 core separately from the crypto module
From: Andy Lutomirski @ 2017-01-10 23:24 UTC (permalink / raw)
To: Daniel Borkmann, Netdev, LKML, Linux Crypto Mailing List
Cc: Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Andy Lutomirski, Ard Biesheuvel, Herbert Xu
In-Reply-To: <cover.1484090585.git.luto@kernel.org>
This just moves code around -- no code changes in this patch. This
wil let BPF-based tracing link against the SHA256 core code without
depending on the crypto core.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
crypto/Kconfig | 8 ++
crypto/Makefile | 1 +
crypto/sha256_direct.c | 238 ++++++++++++++++++++++++++++++++++++++++++++++++
crypto/sha256_generic.c | 214 -------------------------------------------
4 files changed, 247 insertions(+), 214 deletions(-)
create mode 100644 crypto/sha256_direct.c
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 160f08e721cc..b83ae6789e78 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -10,6 +10,13 @@ config XOR_BLOCKS
source "crypto/async_tx/Kconfig"
#
+# Cryptographic algorithms that are usable without the Crypto API.
+# None of these should have visible config options.
+#
+config CRYPTO_SHA256_DIRECT
+ bool
+
+#
# Cryptographic API Configuration
#
menuconfig CRYPTO
@@ -763,6 +770,7 @@ config CRYPTO_SHA512_MB
config CRYPTO_SHA256
tristate "SHA224 and SHA256 digest algorithm"
+ select CRYPTO_SHA256_DIRECT
select CRYPTO_HASH
help
SHA256 secure hash standard (DFIPS 180-2).
diff --git a/crypto/Makefile b/crypto/Makefile
index b8f0e3eb0791..e0118a3b0d99 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_CRYPTO_RMD160) += rmd160.o
obj-$(CONFIG_CRYPTO_RMD256) += rmd256.o
obj-$(CONFIG_CRYPTO_RMD320) += rmd320.o
obj-$(CONFIG_CRYPTO_SHA1) += sha1_generic.o
+obj-$(CONFIG_CRYPTO_SHA256_DIRECT) += sha256_direct.o
obj-$(CONFIG_CRYPTO_SHA256) += sha256_generic.o
obj-$(CONFIG_CRYPTO_SHA512) += sha512_generic.o
obj-$(CONFIG_CRYPTO_SHA3) += sha3_generic.o
diff --git a/crypto/sha256_direct.c b/crypto/sha256_direct.c
new file mode 100644
index 000000000000..2029e4c08339
--- /dev/null
+++ b/crypto/sha256_direct.c
@@ -0,0 +1,238 @@
+/*
+ * Cryptographic API.
+ *
+ * SHA-256, as specified in
+ * http://csrc.nist.gov/groups/STM/cavp/documents/shs/sha256-384-512.pdf
+ *
+ * SHA-256 code by Jean-Luc Cooke <jlcooke@certainkey.com>.
+ *
+ * Copyright (c) Jean-Luc Cooke <jlcooke@certainkey.com>
+ * Copyright (c) Andrew McDonald <andrew@mcdonald.org.uk>
+ * Copyright (c) 2002 James Morris <jmorris@intercode.com.au>
+ * SHA224 Support Copyright 2007 Intel Corporation <jonathan.lynch@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+#include <linux/types.h>
+#include <crypto/sha.h>
+#include <crypto/sha256_base.h>
+#include <asm/byteorder.h>
+#include <asm/unaligned.h>
+
+static inline u32 Ch(u32 x, u32 y, u32 z)
+{
+ return z ^ (x & (y ^ z));
+}
+
+static inline u32 Maj(u32 x, u32 y, u32 z)
+{
+ return (x & y) | (z & (x | y));
+}
+
+#define e0(x) (ror32(x, 2) ^ ror32(x,13) ^ ror32(x,22))
+#define e1(x) (ror32(x, 6) ^ ror32(x,11) ^ ror32(x,25))
+#define s0(x) (ror32(x, 7) ^ ror32(x,18) ^ (x >> 3))
+#define s1(x) (ror32(x,17) ^ ror32(x,19) ^ (x >> 10))
+
+static inline void LOAD_OP(int I, u32 *W, const u8 *input)
+{
+ W[I] = get_unaligned_be32((__u32 *)input + I);
+}
+
+static inline void BLEND_OP(int I, u32 *W)
+{
+ W[I] = s1(W[I-2]) + W[I-7] + s0(W[I-15]) + W[I-16];
+}
+
+static void sha256_transform(u32 *state, const u8 *input)
+{
+ u32 a, b, c, d, e, f, g, h, t1, t2;
+ u32 W[64];
+ int i;
+
+ /* load the input */
+ for (i = 0; i < 16; i++)
+ LOAD_OP(i, W, input);
+
+ /* now blend */
+ for (i = 16; i < 64; i++)
+ BLEND_OP(i, W);
+
+ /* load the state into our registers */
+ a=state[0]; b=state[1]; c=state[2]; d=state[3];
+ e=state[4]; f=state[5]; g=state[6]; h=state[7];
+
+ /* now iterate */
+ t1 = h + e1(e) + Ch(e,f,g) + 0x428a2f98 + W[ 0];
+ t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
+ t1 = g + e1(d) + Ch(d,e,f) + 0x71374491 + W[ 1];
+ t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
+ t1 = f + e1(c) + Ch(c,d,e) + 0xb5c0fbcf + W[ 2];
+ t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
+ t1 = e + e1(b) + Ch(b,c,d) + 0xe9b5dba5 + W[ 3];
+ t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
+ t1 = d + e1(a) + Ch(a,b,c) + 0x3956c25b + W[ 4];
+ t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
+ t1 = c + e1(h) + Ch(h,a,b) + 0x59f111f1 + W[ 5];
+ t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
+ t1 = b + e1(g) + Ch(g,h,a) + 0x923f82a4 + W[ 6];
+ t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
+ t1 = a + e1(f) + Ch(f,g,h) + 0xab1c5ed5 + W[ 7];
+ t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
+
+ t1 = h + e1(e) + Ch(e,f,g) + 0xd807aa98 + W[ 8];
+ t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
+ t1 = g + e1(d) + Ch(d,e,f) + 0x12835b01 + W[ 9];
+ t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
+ t1 = f + e1(c) + Ch(c,d,e) + 0x243185be + W[10];
+ t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
+ t1 = e + e1(b) + Ch(b,c,d) + 0x550c7dc3 + W[11];
+ t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
+ t1 = d + e1(a) + Ch(a,b,c) + 0x72be5d74 + W[12];
+ t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
+ t1 = c + e1(h) + Ch(h,a,b) + 0x80deb1fe + W[13];
+ t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
+ t1 = b + e1(g) + Ch(g,h,a) + 0x9bdc06a7 + W[14];
+ t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
+ t1 = a + e1(f) + Ch(f,g,h) + 0xc19bf174 + W[15];
+ t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
+
+ t1 = h + e1(e) + Ch(e,f,g) + 0xe49b69c1 + W[16];
+ t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
+ t1 = g + e1(d) + Ch(d,e,f) + 0xefbe4786 + W[17];
+ t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
+ t1 = f + e1(c) + Ch(c,d,e) + 0x0fc19dc6 + W[18];
+ t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
+ t1 = e + e1(b) + Ch(b,c,d) + 0x240ca1cc + W[19];
+ t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
+ t1 = d + e1(a) + Ch(a,b,c) + 0x2de92c6f + W[20];
+ t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
+ t1 = c + e1(h) + Ch(h,a,b) + 0x4a7484aa + W[21];
+ t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
+ t1 = b + e1(g) + Ch(g,h,a) + 0x5cb0a9dc + W[22];
+ t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
+ t1 = a + e1(f) + Ch(f,g,h) + 0x76f988da + W[23];
+ t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
+
+ t1 = h + e1(e) + Ch(e,f,g) + 0x983e5152 + W[24];
+ t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
+ t1 = g + e1(d) + Ch(d,e,f) + 0xa831c66d + W[25];
+ t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
+ t1 = f + e1(c) + Ch(c,d,e) + 0xb00327c8 + W[26];
+ t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
+ t1 = e + e1(b) + Ch(b,c,d) + 0xbf597fc7 + W[27];
+ t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
+ t1 = d + e1(a) + Ch(a,b,c) + 0xc6e00bf3 + W[28];
+ t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
+ t1 = c + e1(h) + Ch(h,a,b) + 0xd5a79147 + W[29];
+ t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
+ t1 = b + e1(g) + Ch(g,h,a) + 0x06ca6351 + W[30];
+ t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
+ t1 = a + e1(f) + Ch(f,g,h) + 0x14292967 + W[31];
+ t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
+
+ t1 = h + e1(e) + Ch(e,f,g) + 0x27b70a85 + W[32];
+ t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
+ t1 = g + e1(d) + Ch(d,e,f) + 0x2e1b2138 + W[33];
+ t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
+ t1 = f + e1(c) + Ch(c,d,e) + 0x4d2c6dfc + W[34];
+ t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
+ t1 = e + e1(b) + Ch(b,c,d) + 0x53380d13 + W[35];
+ t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
+ t1 = d + e1(a) + Ch(a,b,c) + 0x650a7354 + W[36];
+ t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
+ t1 = c + e1(h) + Ch(h,a,b) + 0x766a0abb + W[37];
+ t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
+ t1 = b + e1(g) + Ch(g,h,a) + 0x81c2c92e + W[38];
+ t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
+ t1 = a + e1(f) + Ch(f,g,h) + 0x92722c85 + W[39];
+ t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
+
+ t1 = h + e1(e) + Ch(e,f,g) + 0xa2bfe8a1 + W[40];
+ t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
+ t1 = g + e1(d) + Ch(d,e,f) + 0xa81a664b + W[41];
+ t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
+ t1 = f + e1(c) + Ch(c,d,e) + 0xc24b8b70 + W[42];
+ t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
+ t1 = e + e1(b) + Ch(b,c,d) + 0xc76c51a3 + W[43];
+ t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
+ t1 = d + e1(a) + Ch(a,b,c) + 0xd192e819 + W[44];
+ t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
+ t1 = c + e1(h) + Ch(h,a,b) + 0xd6990624 + W[45];
+ t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
+ t1 = b + e1(g) + Ch(g,h,a) + 0xf40e3585 + W[46];
+ t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
+ t1 = a + e1(f) + Ch(f,g,h) + 0x106aa070 + W[47];
+ t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
+
+ t1 = h + e1(e) + Ch(e,f,g) + 0x19a4c116 + W[48];
+ t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
+ t1 = g + e1(d) + Ch(d,e,f) + 0x1e376c08 + W[49];
+ t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
+ t1 = f + e1(c) + Ch(c,d,e) + 0x2748774c + W[50];
+ t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
+ t1 = e + e1(b) + Ch(b,c,d) + 0x34b0bcb5 + W[51];
+ t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
+ t1 = d + e1(a) + Ch(a,b,c) + 0x391c0cb3 + W[52];
+ t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
+ t1 = c + e1(h) + Ch(h,a,b) + 0x4ed8aa4a + W[53];
+ t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
+ t1 = b + e1(g) + Ch(g,h,a) + 0x5b9cca4f + W[54];
+ t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
+ t1 = a + e1(f) + Ch(f,g,h) + 0x682e6ff3 + W[55];
+ t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
+
+ t1 = h + e1(e) + Ch(e,f,g) + 0x748f82ee + W[56];
+ t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
+ t1 = g + e1(d) + Ch(d,e,f) + 0x78a5636f + W[57];
+ t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
+ t1 = f + e1(c) + Ch(c,d,e) + 0x84c87814 + W[58];
+ t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
+ t1 = e + e1(b) + Ch(b,c,d) + 0x8cc70208 + W[59];
+ t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
+ t1 = d + e1(a) + Ch(a,b,c) + 0x90befffa + W[60];
+ t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
+ t1 = c + e1(h) + Ch(h,a,b) + 0xa4506ceb + W[61];
+ t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
+ t1 = b + e1(g) + Ch(g,h,a) + 0xbef9a3f7 + W[62];
+ t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
+ t1 = a + e1(f) + Ch(f,g,h) + 0xc67178f2 + W[63];
+ t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
+
+ state[0] += a; state[1] += b; state[2] += c; state[3] += d;
+ state[4] += e; state[5] += f; state[6] += g; state[7] += h;
+
+ /* clear any sensitive info... */
+ a = b = c = d = e = f = g = h = t1 = t2 = 0;
+ memzero_explicit(W, 64 * sizeof(u32));
+}
+
+static void sha256_generic_block_fn(struct sha256_state *sst, u8 const *src,
+ int blocks)
+{
+ while (blocks--) {
+ sha256_transform(sst->state, src);
+ src += SHA256_BLOCK_SIZE;
+ }
+}
+
+void sha256_update_direct(struct sha256_state *sctx, const u8 *data,
+ unsigned int len)
+{
+ __sha256_base_do_update(sctx, data, len, sha256_generic_block_fn);
+}
+EXPORT_SYMBOL(sha256_update_direct);
+
+void __sha256_final_direct(struct sha256_state *sctx, unsigned int digest_size,
+ u8 *out)
+{
+ sha256_do_finalize_direct(sctx, sha256_generic_block_fn);
+ __sha256_base_finish(sctx, digest_size, out);
+}
+EXPORT_SYMBOL(sha256_final_direct);
+
+MODULE_LICENSE("GPL");
diff --git a/crypto/sha256_generic.c b/crypto/sha256_generic.c
index 573e114382f9..ffc444ef627c 100644
--- a/crypto/sha256_generic.c
+++ b/crypto/sha256_generic.c
@@ -24,8 +24,6 @@
#include <linux/types.h>
#include <crypto/sha.h>
#include <crypto/sha256_base.h>
-#include <asm/byteorder.h>
-#include <asm/unaligned.h>
const u8 sha224_zero_message_hash[SHA224_DIGEST_SIZE] = {
0xd1, 0x4a, 0x02, 0x8c, 0x2a, 0x3a, 0x2b, 0xc9, 0x47,
@@ -43,210 +41,6 @@ const u8 sha256_zero_message_hash[SHA256_DIGEST_SIZE] = {
};
EXPORT_SYMBOL_GPL(sha256_zero_message_hash);
-static inline u32 Ch(u32 x, u32 y, u32 z)
-{
- return z ^ (x & (y ^ z));
-}
-
-static inline u32 Maj(u32 x, u32 y, u32 z)
-{
- return (x & y) | (z & (x | y));
-}
-
-#define e0(x) (ror32(x, 2) ^ ror32(x,13) ^ ror32(x,22))
-#define e1(x) (ror32(x, 6) ^ ror32(x,11) ^ ror32(x,25))
-#define s0(x) (ror32(x, 7) ^ ror32(x,18) ^ (x >> 3))
-#define s1(x) (ror32(x,17) ^ ror32(x,19) ^ (x >> 10))
-
-static inline void LOAD_OP(int I, u32 *W, const u8 *input)
-{
- W[I] = get_unaligned_be32((__u32 *)input + I);
-}
-
-static inline void BLEND_OP(int I, u32 *W)
-{
- W[I] = s1(W[I-2]) + W[I-7] + s0(W[I-15]) + W[I-16];
-}
-
-static void sha256_transform(u32 *state, const u8 *input)
-{
- u32 a, b, c, d, e, f, g, h, t1, t2;
- u32 W[64];
- int i;
-
- /* load the input */
- for (i = 0; i < 16; i++)
- LOAD_OP(i, W, input);
-
- /* now blend */
- for (i = 16; i < 64; i++)
- BLEND_OP(i, W);
-
- /* load the state into our registers */
- a=state[0]; b=state[1]; c=state[2]; d=state[3];
- e=state[4]; f=state[5]; g=state[6]; h=state[7];
-
- /* now iterate */
- t1 = h + e1(e) + Ch(e,f,g) + 0x428a2f98 + W[ 0];
- t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
- t1 = g + e1(d) + Ch(d,e,f) + 0x71374491 + W[ 1];
- t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
- t1 = f + e1(c) + Ch(c,d,e) + 0xb5c0fbcf + W[ 2];
- t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
- t1 = e + e1(b) + Ch(b,c,d) + 0xe9b5dba5 + W[ 3];
- t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
- t1 = d + e1(a) + Ch(a,b,c) + 0x3956c25b + W[ 4];
- t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
- t1 = c + e1(h) + Ch(h,a,b) + 0x59f111f1 + W[ 5];
- t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
- t1 = b + e1(g) + Ch(g,h,a) + 0x923f82a4 + W[ 6];
- t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
- t1 = a + e1(f) + Ch(f,g,h) + 0xab1c5ed5 + W[ 7];
- t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
-
- t1 = h + e1(e) + Ch(e,f,g) + 0xd807aa98 + W[ 8];
- t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
- t1 = g + e1(d) + Ch(d,e,f) + 0x12835b01 + W[ 9];
- t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
- t1 = f + e1(c) + Ch(c,d,e) + 0x243185be + W[10];
- t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
- t1 = e + e1(b) + Ch(b,c,d) + 0x550c7dc3 + W[11];
- t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
- t1 = d + e1(a) + Ch(a,b,c) + 0x72be5d74 + W[12];
- t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
- t1 = c + e1(h) + Ch(h,a,b) + 0x80deb1fe + W[13];
- t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
- t1 = b + e1(g) + Ch(g,h,a) + 0x9bdc06a7 + W[14];
- t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
- t1 = a + e1(f) + Ch(f,g,h) + 0xc19bf174 + W[15];
- t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
-
- t1 = h + e1(e) + Ch(e,f,g) + 0xe49b69c1 + W[16];
- t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
- t1 = g + e1(d) + Ch(d,e,f) + 0xefbe4786 + W[17];
- t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
- t1 = f + e1(c) + Ch(c,d,e) + 0x0fc19dc6 + W[18];
- t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
- t1 = e + e1(b) + Ch(b,c,d) + 0x240ca1cc + W[19];
- t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
- t1 = d + e1(a) + Ch(a,b,c) + 0x2de92c6f + W[20];
- t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
- t1 = c + e1(h) + Ch(h,a,b) + 0x4a7484aa + W[21];
- t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
- t1 = b + e1(g) + Ch(g,h,a) + 0x5cb0a9dc + W[22];
- t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
- t1 = a + e1(f) + Ch(f,g,h) + 0x76f988da + W[23];
- t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
-
- t1 = h + e1(e) + Ch(e,f,g) + 0x983e5152 + W[24];
- t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
- t1 = g + e1(d) + Ch(d,e,f) + 0xa831c66d + W[25];
- t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
- t1 = f + e1(c) + Ch(c,d,e) + 0xb00327c8 + W[26];
- t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
- t1 = e + e1(b) + Ch(b,c,d) + 0xbf597fc7 + W[27];
- t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
- t1 = d + e1(a) + Ch(a,b,c) + 0xc6e00bf3 + W[28];
- t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
- t1 = c + e1(h) + Ch(h,a,b) + 0xd5a79147 + W[29];
- t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
- t1 = b + e1(g) + Ch(g,h,a) + 0x06ca6351 + W[30];
- t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
- t1 = a + e1(f) + Ch(f,g,h) + 0x14292967 + W[31];
- t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
-
- t1 = h + e1(e) + Ch(e,f,g) + 0x27b70a85 + W[32];
- t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
- t1 = g + e1(d) + Ch(d,e,f) + 0x2e1b2138 + W[33];
- t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
- t1 = f + e1(c) + Ch(c,d,e) + 0x4d2c6dfc + W[34];
- t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
- t1 = e + e1(b) + Ch(b,c,d) + 0x53380d13 + W[35];
- t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
- t1 = d + e1(a) + Ch(a,b,c) + 0x650a7354 + W[36];
- t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
- t1 = c + e1(h) + Ch(h,a,b) + 0x766a0abb + W[37];
- t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
- t1 = b + e1(g) + Ch(g,h,a) + 0x81c2c92e + W[38];
- t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
- t1 = a + e1(f) + Ch(f,g,h) + 0x92722c85 + W[39];
- t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
-
- t1 = h + e1(e) + Ch(e,f,g) + 0xa2bfe8a1 + W[40];
- t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
- t1 = g + e1(d) + Ch(d,e,f) + 0xa81a664b + W[41];
- t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
- t1 = f + e1(c) + Ch(c,d,e) + 0xc24b8b70 + W[42];
- t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
- t1 = e + e1(b) + Ch(b,c,d) + 0xc76c51a3 + W[43];
- t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
- t1 = d + e1(a) + Ch(a,b,c) + 0xd192e819 + W[44];
- t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
- t1 = c + e1(h) + Ch(h,a,b) + 0xd6990624 + W[45];
- t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
- t1 = b + e1(g) + Ch(g,h,a) + 0xf40e3585 + W[46];
- t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
- t1 = a + e1(f) + Ch(f,g,h) + 0x106aa070 + W[47];
- t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
-
- t1 = h + e1(e) + Ch(e,f,g) + 0x19a4c116 + W[48];
- t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
- t1 = g + e1(d) + Ch(d,e,f) + 0x1e376c08 + W[49];
- t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
- t1 = f + e1(c) + Ch(c,d,e) + 0x2748774c + W[50];
- t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
- t1 = e + e1(b) + Ch(b,c,d) + 0x34b0bcb5 + W[51];
- t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
- t1 = d + e1(a) + Ch(a,b,c) + 0x391c0cb3 + W[52];
- t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
- t1 = c + e1(h) + Ch(h,a,b) + 0x4ed8aa4a + W[53];
- t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
- t1 = b + e1(g) + Ch(g,h,a) + 0x5b9cca4f + W[54];
- t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
- t1 = a + e1(f) + Ch(f,g,h) + 0x682e6ff3 + W[55];
- t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
-
- t1 = h + e1(e) + Ch(e,f,g) + 0x748f82ee + W[56];
- t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
- t1 = g + e1(d) + Ch(d,e,f) + 0x78a5636f + W[57];
- t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
- t1 = f + e1(c) + Ch(c,d,e) + 0x84c87814 + W[58];
- t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
- t1 = e + e1(b) + Ch(b,c,d) + 0x8cc70208 + W[59];
- t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
- t1 = d + e1(a) + Ch(a,b,c) + 0x90befffa + W[60];
- t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
- t1 = c + e1(h) + Ch(h,a,b) + 0xa4506ceb + W[61];
- t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
- t1 = b + e1(g) + Ch(g,h,a) + 0xbef9a3f7 + W[62];
- t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
- t1 = a + e1(f) + Ch(f,g,h) + 0xc67178f2 + W[63];
- t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
-
- state[0] += a; state[1] += b; state[2] += c; state[3] += d;
- state[4] += e; state[5] += f; state[6] += g; state[7] += h;
-
- /* clear any sensitive info... */
- a = b = c = d = e = f = g = h = t1 = t2 = 0;
- memzero_explicit(W, 64 * sizeof(u32));
-}
-
-static void sha256_generic_block_fn(struct sha256_state *sst, u8 const *src,
- int blocks)
-{
- while (blocks--) {
- sha256_transform(sst->state, src);
- src += SHA256_BLOCK_SIZE;
- }
-}
-
-void sha256_update_direct(struct sha256_state *sctx, const u8 *data,
- unsigned int len)
-{
- __sha256_base_do_update(sctx, data, len, sha256_generic_block_fn);
-}
-EXPORT_SYMBOL(sha256_update_direct);
-
int crypto_sha256_update(struct shash_desc *desc, const u8 *data,
unsigned int len)
{
@@ -262,14 +56,6 @@ static int sha256_final(struct shash_desc *desc, u8 *out)
return 0;
}
-void __sha256_final_direct(struct sha256_state *sctx, unsigned int digest_size,
- u8 *out)
-{
- sha256_do_finalize_direct(sctx, sha256_generic_block_fn);
- __sha256_base_finish(sctx, digest_size, out);
-}
-EXPORT_SYMBOL(sha256_final_direct);
-
int crypto_sha256_finup(struct shash_desc *desc, const u8 *data,
unsigned int len, u8 *hash)
{
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/8] bpf: Use SHA256 instead of SHA1 for bpf digests
From: Andy Lutomirski @ 2017-01-10 23:24 UTC (permalink / raw)
To: Daniel Borkmann, Netdev, LKML, Linux Crypto Mailing List
Cc: Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Andy Lutomirski, Alexei Starovoitov
In-Reply-To: <cover.1484090585.git.luto@kernel.org>
SHA1 is considered obsolete. It is no longer considered to be
collision resistant and, in general, it should not be used for new
applications. Change the new-in-4.10 BPF digest to SHA-256. This
means that potential future applications of the digest that need
collision resistance will be able to use the BPF digest. Applications
that just want a short identifier for a BPF program are welcome to
truncate the digest.
This is also a cleanup IMO -- the new sha256_*_direct() API is much
nicer than the old SHA1 library helpers. It will also enable
incremental hashing so the BPF code can avoid calling vmalloc().
I moved the digest field to keep all of the bpf program metadata in
the same cache line.
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
include/linux/filter.h | 11 +++--------
init/Kconfig | 1 +
kernel/bpf/core.c | 42 ++++++++----------------------------------
3 files changed, 12 insertions(+), 42 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 702314253797..23df2574e30c 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -14,7 +14,8 @@
#include <linux/workqueue.h>
#include <linux/sched.h>
#include <linux/capability.h>
-#include <linux/cryptohash.h>
+
+#include <crypto/sha.h>
#include <net/sch_generic.h>
@@ -408,11 +409,11 @@ struct bpf_prog {
kmemcheck_bitfield_end(meta);
enum bpf_prog_type type; /* Type of BPF program */
u32 len; /* Number of filter blocks */
- u32 digest[SHA_DIGEST_WORDS]; /* Program digest */
struct bpf_prog_aux *aux; /* Auxiliary fields */
struct sock_fprog_kern *orig_prog; /* Original BPF program */
unsigned int (*bpf_func)(const void *ctx,
const struct bpf_insn *insn);
+ u8 digest[SHA256_DIGEST_SIZE]; /* Program digest */
/* Instructions for interpreter */
union {
struct sock_filter insns[0];
@@ -519,12 +520,6 @@ static inline u32 bpf_prog_insn_size(const struct bpf_prog *prog)
return prog->len * sizeof(struct bpf_insn);
}
-static inline u32 bpf_prog_digest_scratch_size(const struct bpf_prog *prog)
-{
- return round_up(bpf_prog_insn_size(prog) +
- sizeof(__be64) + 1, SHA_MESSAGE_BYTES);
-}
-
static inline unsigned int bpf_prog_size(unsigned int proglen)
{
return max(sizeof(struct bpf_prog),
diff --git a/init/Kconfig b/init/Kconfig
index 223b734abccd..f1ea6d023f8c 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1389,6 +1389,7 @@ config HAVE_PCSPKR_PLATFORM
# interpreter that classic socket filters depend on
config BPF
bool
+ select CRYPTO_SHA256_DIRECT
menuconfig EXPERT
bool "Configure standard kernel features (expert users)"
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 1eb4f1303756..668b92f6ab58 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -148,22 +148,18 @@ void __bpf_prog_free(struct bpf_prog *fp)
int bpf_prog_calc_digest(struct bpf_prog *fp)
{
- const u32 bits_offset = SHA_MESSAGE_BYTES - sizeof(__be64);
- u32 raw_size = bpf_prog_digest_scratch_size(fp);
- u32 ws[SHA_WORKSPACE_WORDS];
- u32 i, bsize, psize, blocks;
+ struct sha256_state sha;
+ u32 i, psize;
struct bpf_insn *dst;
bool was_ld_map;
- u8 *raw, *todo;
- __be32 *result;
- __be64 *bits;
+ u8 *raw;
- raw = vmalloc(raw_size);
+ psize = bpf_prog_insn_size(fp);
+ raw = vmalloc(psize);
if (!raw)
return -ENOMEM;
- sha_init(fp->digest);
- memset(ws, 0, sizeof(ws));
+ sha256_init_direct(&sha);
/* We need to take out the map fd for the digest calculation
* since they are unstable from user space side.
@@ -188,30 +184,8 @@ int bpf_prog_calc_digest(struct bpf_prog *fp)
}
}
- psize = bpf_prog_insn_size(fp);
- memset(&raw[psize], 0, raw_size - psize);
- raw[psize++] = 0x80;
-
- bsize = round_up(psize, SHA_MESSAGE_BYTES);
- blocks = bsize / SHA_MESSAGE_BYTES;
- todo = raw;
- if (bsize - psize >= sizeof(__be64)) {
- bits = (__be64 *)(todo + bsize - sizeof(__be64));
- } else {
- bits = (__be64 *)(todo + bsize + bits_offset);
- blocks++;
- }
- *bits = cpu_to_be64((psize - 1) << 3);
-
- while (blocks--) {
- sha_transform(fp->digest, todo, ws);
- todo += SHA_MESSAGE_BYTES;
- }
-
- result = (__force __be32 *)fp->digest;
- for (i = 0; i < SHA_DIGEST_WORDS; i++)
- result[i] = cpu_to_be32(fp->digest[i]);
-
+ sha256_update_direct(&sha, raw, psize);
+ sha256_final_direct(&sha, fp->digest);
vfree(raw);
return 0;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/8] bpf: Rename fdinfo's prog_digest to prog_sha256
From: Andy Lutomirski @ 2017-01-10 23:24 UTC (permalink / raw)
To: Daniel Borkmann, Netdev, LKML, Linux Crypto Mailing List
Cc: Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Andy Lutomirski, Alexei Starovoitov
In-Reply-To: <cover.1484090585.git.luto@kernel.org>
This makes it easier to add another digest algorithm down the road
if needed. It also serves to force any programs that might have
been written against a kernel that had 'prog_digest' to be updated.
This shouldn't violate any stable API policies, as no released
kernel has ever had 'prog_digest'.
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
kernel/bpf/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index e89acea22ecf..956370b80296 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -694,7 +694,7 @@ static void bpf_prog_show_fdinfo(struct seq_file *m, struct file *filp)
seq_printf(m,
"prog_type:\t%u\n"
"prog_jited:\t%u\n"
- "prog_digest:\t%s\n"
+ "prog_sha256:\t%s\n"
"memlock:\t%llu\n",
prog->type,
prog->jited,
--
2.9.3
^ permalink raw reply related
* [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests
From: Andy Lutomirski @ 2017-01-10 23:24 UTC (permalink / raw)
To: Daniel Borkmann, Netdev, LKML, Linux Crypto Mailing List
Cc: Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Andy Lutomirski, Ard Biesheuvel, Herbert Xu
In-Reply-To: <cover.1484090585.git.luto@kernel.org>
There are some hashes (e.g. sha224) that have some internal trickery
to make sure that only the correct number of output bytes are
generated. If something goes wrong, they could potentially overrun
the output buffer.
Make the test more robust by allocating only enough space for the
correct output size so that memory debugging will catch the error if
the output is overrun.
Tested by intentionally breaking sha224 to output all 256
internally-generated bits while running on KASAN.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
crypto/testmgr.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index f616ad74cce7..575fc28a9ab2 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -265,6 +265,7 @@ static int __test_hash(struct crypto_ahash *tfm, struct hash_testvec *template,
const int align_offset)
{
const char *algo = crypto_tfm_alg_driver_name(crypto_ahash_tfm(tfm));
+ size_t digest_size = crypto_ahash_digestsize(tfm);
unsigned int i, j, k, temp;
struct scatterlist sg[8];
char *result;
@@ -275,7 +276,7 @@ static int __test_hash(struct crypto_ahash *tfm, struct hash_testvec *template,
char *xbuf[XBUFSIZE];
int ret = -ENOMEM;
- result = kmalloc(MAX_DIGEST_SIZE, GFP_KERNEL);
+ result = kmalloc(digest_size, GFP_KERNEL);
if (!result)
return ret;
key = kmalloc(MAX_KEYLEN, GFP_KERNEL);
@@ -305,7 +306,7 @@ static int __test_hash(struct crypto_ahash *tfm, struct hash_testvec *template,
goto out;
j++;
- memset(result, 0, MAX_DIGEST_SIZE);
+ memset(result, 0, digest_size);
hash_buff = xbuf[0];
hash_buff += align_offset;
@@ -380,7 +381,7 @@ static int __test_hash(struct crypto_ahash *tfm, struct hash_testvec *template,
continue;
j++;
- memset(result, 0, MAX_DIGEST_SIZE);
+ memset(result, 0, digest_size);
temp = 0;
sg_init_table(sg, template[i].np);
@@ -458,7 +459,7 @@ static int __test_hash(struct crypto_ahash *tfm, struct hash_testvec *template,
continue;
j++;
- memset(result, 0, MAX_DIGEST_SIZE);
+ memset(result, 0, digest_size);
ret = -EINVAL;
hash_buff = xbuf[0];
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/8] bpf: Avoid copying the entire BPF program when hashing it
From: Andy Lutomirski @ 2017-01-10 23:24 UTC (permalink / raw)
To: Daniel Borkmann, Netdev, LKML, Linux Crypto Mailing List
Cc: Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Andy Lutomirski, Alexei Starovoitov
In-Reply-To: <cover.1484090585.git.luto@kernel.org>
The sha256 helpers can consume a message incrementally, so there's no need
to allocate a buffer to store the whole blob to be hashed.
This may be a slight slowdown for very long messages because gcc can't
inline the sha256_update() calls. For reasonably-sized programs,
however, this should be a considerable speedup as vmalloc() is quite
slow.
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
kernel/bpf/core.c | 33 +++++++++++++--------------------
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 668b92f6ab58..106162a1bc54 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -149,44 +149,37 @@ void __bpf_prog_free(struct bpf_prog *fp)
int bpf_prog_calc_digest(struct bpf_prog *fp)
{
struct sha256_state sha;
- u32 i, psize;
- struct bpf_insn *dst;
+ u32 i;
bool was_ld_map;
- u8 *raw;
-
- psize = bpf_prog_insn_size(fp);
- raw = vmalloc(psize);
- if (!raw)
- return -ENOMEM;
sha256_init_direct(&sha);
/* We need to take out the map fd for the digest calculation
* since they are unstable from user space side.
*/
- dst = (void *)raw;
for (i = 0, was_ld_map = false; i < fp->len; i++) {
- dst[i] = fp->insnsi[i];
+ struct bpf_insn insn = fp->insnsi[i];
+
if (!was_ld_map &&
- dst[i].code == (BPF_LD | BPF_IMM | BPF_DW) &&
- dst[i].src_reg == BPF_PSEUDO_MAP_FD) {
+ insn.code == (BPF_LD | BPF_IMM | BPF_DW) &&
+ insn.src_reg == BPF_PSEUDO_MAP_FD) {
was_ld_map = true;
- dst[i].imm = 0;
+ insn.imm = 0;
} else if (was_ld_map &&
- dst[i].code == 0 &&
- dst[i].dst_reg == 0 &&
- dst[i].src_reg == 0 &&
- dst[i].off == 0) {
+ insn.code == 0 &&
+ insn.dst_reg == 0 &&
+ insn.src_reg == 0 &&
+ insn.off == 0) {
was_ld_map = false;
- dst[i].imm = 0;
+ insn.imm = 0;
} else {
was_ld_map = false;
}
+
+ sha256_update_direct(&sha, (const u8 *)&insn, sizeof(insn));
}
- sha256_update_direct(&sha, raw, psize);
sha256_final_direct(&sha, fp->digest);
- vfree(raw);
return 0;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256
From: Andy Lutomirski @ 2017-01-10 23:24 UTC (permalink / raw)
To: Daniel Borkmann, Netdev, LKML, Linux Crypto Mailing List
Cc: Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Andy Lutomirski, Alexei Starovoitov
In-Reply-To: <cover.1484090585.git.luto@kernel.org>
This makes it easier to add another digest algorithm down the road if
needed. It also serves to force any programs that might have been
written against a kernel that had the old field name to notice the
change and make any necessary changes.
This shouldn't violate any stable API policies, as no released kernel
has ever had TCA*BPF_DIGEST.
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
include/uapi/linux/pkt_cls.h | 2 +-
include/uapi/linux/tc_act/tc_bpf.h | 2 +-
net/sched/act_bpf.c | 2 +-
net/sched/cls_bpf.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index cb4bcdc58543..ac6b300c1550 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -397,7 +397,7 @@ enum {
TCA_BPF_NAME,
TCA_BPF_FLAGS,
TCA_BPF_FLAGS_GEN,
- TCA_BPF_DIGEST,
+ TCA_BPF_SHA256,
__TCA_BPF_MAX,
};
diff --git a/include/uapi/linux/tc_act/tc_bpf.h b/include/uapi/linux/tc_act/tc_bpf.h
index a6b88a6f7f71..eae18a7430eb 100644
--- a/include/uapi/linux/tc_act/tc_bpf.h
+++ b/include/uapi/linux/tc_act/tc_bpf.h
@@ -27,7 +27,7 @@ enum {
TCA_ACT_BPF_FD,
TCA_ACT_BPF_NAME,
TCA_ACT_BPF_PAD,
- TCA_ACT_BPF_DIGEST,
+ TCA_ACT_BPF_SHA256,
__TCA_ACT_BPF_MAX,
};
#define TCA_ACT_BPF_MAX (__TCA_ACT_BPF_MAX - 1)
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
index 1c60317f0121..3868a66d0b24 100644
--- a/net/sched/act_bpf.c
+++ b/net/sched/act_bpf.c
@@ -123,7 +123,7 @@ static int tcf_bpf_dump_ebpf_info(const struct tcf_bpf *prog,
nla_put_string(skb, TCA_ACT_BPF_NAME, prog->bpf_name))
return -EMSGSIZE;
- nla = nla_reserve(skb, TCA_ACT_BPF_DIGEST,
+ nla = nla_reserve(skb, TCA_ACT_BPF_SHA256,
sizeof(prog->filter->digest));
if (nla == NULL)
return -EMSGSIZE;
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index adc776048d1a..6fc110321621 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -555,7 +555,7 @@ static int cls_bpf_dump_ebpf_info(const struct cls_bpf_prog *prog,
nla_put_string(skb, TCA_BPF_NAME, prog->bpf_name))
return -EMSGSIZE;
- nla = nla_reserve(skb, TCA_BPF_DIGEST, sizeof(prog->filter->digest));
+ nla = nla_reserve(skb, TCA_BPF_SHA256, sizeof(prog->filter->digest));
if (nla == NULL)
return -EMSGSIZE;
--
2.9.3
^ permalink raw reply related
* 4.9.2 panic, __skb_flow_dissect, gro?
From: Denys Fedoryshchenko @ 2017-01-10 23:26 UTC (permalink / raw)
To: Linux Kernel Network Developers
Hi,
Got panic message on 4.9.2 with latest patches from stable-queue,
probably it affects all 4.9 version
Panic message:
dmesg-erst-6374119981415661569:<6>[ 23.110324] ip_set: protocol 6
dmesg-erst-6374119981415661569:<1>[ 28.117455] BUG: unable to handle
kernel NULL pointer dereference at 0000000000000078
dmesg-erst-6374119981415661569:<1>[ 28.118036] IP:
[<ffffffff8188f9de>] __skb_flow_dissect+0x73f/0x931
dmesg-erst-6374119981415661569:<4>[ 28.118360] PGD 0
dmesg-erst-6374119981415661569:<4>[ 28.118427]
dmesg-erst-6374119981415661569:<4>[ 28.118730] Oops: 0000 [#1] SMP
dmesg-erst-6374119981415661569:<4>[ 28.118977] Modules linked in:
xt_TCPMSS xt_connmark ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat
xt_rateest xt_RATEEST nf_conntrack_pptp nf_conntrack_proto_gre xt_CT
xt_set xt_hl xt_tcpudp ip_set_hash_net ip_set nfnetlink iptable_raw
iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_filter ip_tables x_tables 8021q garp mrp stp
llc netconsole configfs bonding ixgbe dca ipmi_watchdog ipmi_si
acpi_ipmi ipmi_msghandler
dmesg-erst-6374119981415661569:<4>[ 28.122784] CPU: 4 PID: 0 Comm:
swapper/4 Not tainted 4.9.2-build-0127 #3
dmesg-erst-6374119981415661569:<4>[ 28.123042] Hardware name: Intel
Corporation S2600WTT/S2600WTT, BIOS SE5C610.86B.01.01.0019.101220160604
10/12/2016
dmesg-erst-6374119981415661569:<4>[ 28.123488] task: ffff882fa6af24c0
task.stack: ffffc90031338000
dmesg-erst-6374119981415661569:<4>[ 28.123742] RIP:
0010:[<ffffffff8188f9de>] [<ffffffff8188f9de>]
__skb_flow_dissect+0x73f/0x931
dmesg-erst-6374119981415661569:<4>[ 28.124243] RSP:
0018:ffff882fbfb03ce8 EFLAGS: 00010206
dmesg-erst-6374119981415661569:<4>[ 28.124497] RAX: 0000000000000130
RBX: 0000000000000022 RCX: ffff882f9eabb000
dmesg-erst-6374119981415661569:<4>[ 28.124756] RDX: 0000000000000010
RSI: ffff882f9eabb026 RDI: 000000000000002f
dmesg-erst-6374119981415661569:<4>[ 28.125015] RBP: ffff882fbfb03d78
R08: 000000000000000c R09: ffff882f9eabb022
dmesg-erst-6374119981415661569:<4>[ 28.125275] R10: 0000000000000140
R11: 0000000000000001 R12: 0000000000000b88
dmesg-erst-6374119981415661569:<4>[ 28.125532] R13: ffff882fbfb03d9c
R14: 0000000000000000 R15: ffffffff820c11a0
dmesg-erst-6374119981415661569:<4>[ 28.125792] FS:
0000000000000000(0000) GS:ffff882fbfb00000(0000) knlGS:0000000000000000
dmesg-erst-6374119981415661569:<4>[ 28.126227] CS: 0010 DS: 0000 ES:
0000 CR0: 0000000080050033
dmesg-erst-6374119981415661569:<4>[ 28.126482] CR2: 0000000000000078
CR3: 000000607f007000 CR4: 00000000001406e0
dmesg-erst-6374119981415661569:<4>[ 28.126741] Stack:
dmesg-erst-6374119981415661569:<4>[ 28.126983] ffff882fbfb03cf8
ffffffff81885afb 00000001bfb03d88 ffffffff818953b5
dmesg-erst-6374119981415661569:<4>[ 28.127675] ffff882fbfb03d9c
2f00000800000000 ffff882f9eabb000 ffff882fbfb03d48
dmesg-erst-6374119981415661569:<4>[ 28.128350] ffffffff818ef3e4
ffff882fa4177400 000000000000004e 0000000000000000
dmesg-erst-6374119981415661569:<4>[ 28.129027] Call Trace:
dmesg-erst-6374119981415661569:<4>[ 28.129271] <IRQ>
dmesg-erst-6374119981415661569:<4>[ 28.129340] [<ffffffff81885afb>] ?
kfree_skb+0x25/0x27
dmesg-erst-6374119981415661569:<4>[ 28.129655] [<ffffffff818953b5>] ?
__netif_receive_skb_core+0x61b/0x807
dmesg-erst-6374119981415661569:<4>[ 28.129917] [<ffffffff818ef3e4>] ?
udp4_gro_receive+0x1f6/0x256
dmesg-erst-6374119981415661569:<4>[ 28.130174] [<ffffffff818b43d3>]
eth_get_headlen+0x4c/0x82
dmesg-erst-6374119981415661569:<4>[ 28.130435] [<ffffffffa003624f>]
ixgbe_clean_rx_irq+0x546/0x924 [ixgbe]
dmesg-erst-6374119981415661569:<4>[ 28.130694] [<ffffffffa003723a>]
ixgbe_poll+0x4ef/0x679 [ixgbe]
dmesg-erst-6374119981415661569:<4>[ 28.130952] [<ffffffff81896b60>]
net_rx_action+0x107/0x27d
dmesg-erst-6374119981415661569:<4>[ 28.131207] [<ffffffff810d18c8>]
__do_softirq+0xb5/0x1a3
dmesg-erst-6374119981415661569:<4>[ 28.131460] [<ffffffff810d1b2d>]
irq_exit+0x4d/0x8e
dmesg-erst-6374119981415661569:<4>[ 28.131712] [<ffffffff81016bb7>]
do_IRQ+0xaa/0xc2
dmesg-erst-6374119981415661569:<4>[ 28.131965] [<ffffffff8191483c>]
common_interrupt+0x7c/0x7c
dmesg-erst-6374119981415661569:<4>[ 28.132217] <EOI>
dmesg-erst-6374119981415661569:<4>[ 28.132286] [<ffffffff81913936>] ?
mwait_idle+0x4e/0x61
dmesg-erst-6374119981415661569:<4>[ 28.132773] [<ffffffff8101cb40>]
arch_cpu_idle+0xa/0xc
dmesg-erst-6374119981415661569:<4>[ 28.133026] [<ffffffff81913a4b>]
default_idle_call+0x20/0x22
dmesg-erst-6374119981415661569:<4>[ 28.133282] [<ffffffff810fa1a5>]
cpu_startup_entry+0xde/0x185
dmesg-erst-6374119981415661569:<4>[ 28.133539] [<ffffffff8102bda3>]
start_secondary+0xe8/0xeb
dmesg-erst-6374119981415661569:<4>[ 28.133792] Code: f7 e8 eb 63 ff ff
85 c0 0f 88 d5 01 00 00 44 8b 45 80 48 8d 75 b0 66 44 8b 66 0c 41 83 c0
0e e9 87 00 00 00 41 8d 50 04 66 85 c0 <41> 8b 46 78 44 0f 48 c2 41 2b
46 7c 42 8d 34 03 29 f0 83 f8 03
dmesg-erst-6374119981415661569:<1>[ 28.138401] RIP
[<ffffffff8188f9de>] __skb_flow_dissect+0x73f/0x931
dmesg-erst-6374119981415661569:<4>[ 28.138718] RSP <ffff882fbfb03ce8>
dmesg-erst-6374119981415661569:<4>[ 28.138964] CR2: 0000000000000078
dmesg-erst-6374119981415661569:<4>[ 28.139215] ---[ end trace
46fb1cf5af272d67 ]---
^ permalink raw reply
* [PATCH iproute2] rttable: Fix invalid range checking when table id is converted to u32
From: David Ahern @ 2017-01-10 23:33 UTC (permalink / raw)
To: netdev, stephen; +Cc: frank.kellermann, David Ahern
Frank reported that table ids for very large numbers are not properly
detected:
$ ip li add foobar type vrf table 98765432100123456789
command succeeds and resulting table id is actually:
21: foobar: <NOARP,MASTER> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether da:ea:d4:77:38:2a brd ff:ff:ff:ff:ff:ff promiscuity 0
vrf table 4294967295 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
Make the temp variable 'i' unsigned long and let the typecast to u32
happen on assignment to id.
Reported-by: Frank Kellermann <frank.kellermann@atos.net>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
lib/rt_names.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rt_names.c b/lib/rt_names.c
index c66cb1e439e3..63687586508b 100644
--- a/lib/rt_names.c
+++ b/lib/rt_names.c
@@ -404,7 +404,7 @@ int rtnl_rttable_a2n(__u32 *id, const char *arg)
static unsigned long res;
struct rtnl_hash_entry *entry;
char *end;
- __u32 i;
+ unsigned long i;
if (cache && strcmp(cache, arg) == 0) {
*id = res;
--
2.1.4
^ permalink raw reply related
* Re: 4.9.2 panic, __skb_flow_dissect, gro?
From: Denys Fedoryshchenko @ 2017-01-10 23:49 UTC (permalink / raw)
To: Linux Kernel Network Developers; +Cc: Ian Kumlien
In-Reply-To: <359da98eb44a5a9f9f286cc380143654@nuclearcat.com>
It seems this patch solve issue. I hope it will go to stable asap,
because without it loaded routers crashing almost instantly on 4.9.
commit d0af683407a26a4437d8fa6e283ea201f2ae8146 (patch)
tree e769779cf59b0b73333b50a68db5d0b8897a7cb6 /net/core/flow_dissector.c
parent 94ba998b63c41e92da1b2f0cd8679e038181ef48 (diff)
flow_dissector: Update pptp handling to avoid null pointer deref.
__skb_flow_dissect can be called with a skb or a data packet, either
can be NULL. All calls seems to have been moved to __skb_header_pointer
except the pptp handling which is still calling skb_header_pointer.
On 2017-01-11 01:26, Denys Fedoryshchenko wrote:
> Hi,
>
> Got panic message on 4.9.2 with latest patches from stable-queue,
> probably it affects all 4.9 version
>
> Panic message:
>
> dmesg-erst-6374119981415661569:<6>[ 23.110324] ip_set: protocol 6
> dmesg-erst-6374119981415661569:<1>[ 28.117455] BUG: unable to handle
> kernel NULL pointer dereference at 0000000000000078
> dmesg-erst-6374119981415661569:<1>[ 28.118036] IP:
> [<ffffffff8188f9de>] __skb_flow_dissect+0x73f/0x931
> dmesg-erst-6374119981415661569:<4>[ 28.118360] PGD 0
> dmesg-erst-6374119981415661569:<4>[ 28.118427]
> dmesg-erst-6374119981415661569:<4>[ 28.118730] Oops: 0000 [#1] SMP
> dmesg-erst-6374119981415661569:<4>[ 28.118977] Modules linked in:
> xt_TCPMSS xt_connmark ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat
> xt_rateest xt_RATEEST nf_conntrack_pptp nf_conntrack_proto_gre xt_CT
> xt_set xt_hl xt_tcpudp ip_set_hash_net ip_set nfnetlink iptable_raw
> iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
> nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables
> 8021q garp mrp stp llc netconsole configfs bonding ixgbe dca
> ipmi_watchdog ipmi_si acpi_ipmi ipmi_msghandler
> dmesg-erst-6374119981415661569:<4>[ 28.122784] CPU: 4 PID: 0 Comm:
> swapper/4 Not tainted 4.9.2-build-0127 #3
> dmesg-erst-6374119981415661569:<4>[ 28.123042] Hardware name: Intel
> Corporation S2600WTT/S2600WTT, BIOS
> SE5C610.86B.01.01.0019.101220160604 10/12/2016
> dmesg-erst-6374119981415661569:<4>[ 28.123488] task:
> ffff882fa6af24c0 task.stack: ffffc90031338000
> dmesg-erst-6374119981415661569:<4>[ 28.123742] RIP:
> 0010:[<ffffffff8188f9de>] [<ffffffff8188f9de>]
> __skb_flow_dissect+0x73f/0x931
> dmesg-erst-6374119981415661569:<4>[ 28.124243] RSP:
> 0018:ffff882fbfb03ce8 EFLAGS: 00010206
> dmesg-erst-6374119981415661569:<4>[ 28.124497] RAX: 0000000000000130
> RBX: 0000000000000022 RCX: ffff882f9eabb000
> dmesg-erst-6374119981415661569:<4>[ 28.124756] RDX: 0000000000000010
> RSI: ffff882f9eabb026 RDI: 000000000000002f
> dmesg-erst-6374119981415661569:<4>[ 28.125015] RBP: ffff882fbfb03d78
> R08: 000000000000000c R09: ffff882f9eabb022
> dmesg-erst-6374119981415661569:<4>[ 28.125275] R10: 0000000000000140
> R11: 0000000000000001 R12: 0000000000000b88
> dmesg-erst-6374119981415661569:<4>[ 28.125532] R13: ffff882fbfb03d9c
> R14: 0000000000000000 R15: ffffffff820c11a0
> dmesg-erst-6374119981415661569:<4>[ 28.125792] FS:
> 0000000000000000(0000) GS:ffff882fbfb00000(0000)
> knlGS:0000000000000000
> dmesg-erst-6374119981415661569:<4>[ 28.126227] CS: 0010 DS: 0000
> ES: 0000 CR0: 0000000080050033
> dmesg-erst-6374119981415661569:<4>[ 28.126482] CR2: 0000000000000078
> CR3: 000000607f007000 CR4: 00000000001406e0
> dmesg-erst-6374119981415661569:<4>[ 28.126741] Stack:
> dmesg-erst-6374119981415661569:<4>[ 28.126983] ffff882fbfb03cf8
> ffffffff81885afb 00000001bfb03d88 ffffffff818953b5
> dmesg-erst-6374119981415661569:<4>[ 28.127675] ffff882fbfb03d9c
> 2f00000800000000 ffff882f9eabb000 ffff882fbfb03d48
> dmesg-erst-6374119981415661569:<4>[ 28.128350] ffffffff818ef3e4
> ffff882fa4177400 000000000000004e 0000000000000000
> dmesg-erst-6374119981415661569:<4>[ 28.129027] Call Trace:
> dmesg-erst-6374119981415661569:<4>[ 28.129271] <IRQ>
> dmesg-erst-6374119981415661569:<4>[ 28.129340] [<ffffffff81885afb>]
> ? kfree_skb+0x25/0x27
> dmesg-erst-6374119981415661569:<4>[ 28.129655] [<ffffffff818953b5>]
> ? __netif_receive_skb_core+0x61b/0x807
> dmesg-erst-6374119981415661569:<4>[ 28.129917] [<ffffffff818ef3e4>]
> ? udp4_gro_receive+0x1f6/0x256
> dmesg-erst-6374119981415661569:<4>[ 28.130174] [<ffffffff818b43d3>]
> eth_get_headlen+0x4c/0x82
> dmesg-erst-6374119981415661569:<4>[ 28.130435] [<ffffffffa003624f>]
> ixgbe_clean_rx_irq+0x546/0x924 [ixgbe]
> dmesg-erst-6374119981415661569:<4>[ 28.130694] [<ffffffffa003723a>]
> ixgbe_poll+0x4ef/0x679 [ixgbe]
> dmesg-erst-6374119981415661569:<4>[ 28.130952] [<ffffffff81896b60>]
> net_rx_action+0x107/0x27d
> dmesg-erst-6374119981415661569:<4>[ 28.131207] [<ffffffff810d18c8>]
> __do_softirq+0xb5/0x1a3
> dmesg-erst-6374119981415661569:<4>[ 28.131460] [<ffffffff810d1b2d>]
> irq_exit+0x4d/0x8e
> dmesg-erst-6374119981415661569:<4>[ 28.131712] [<ffffffff81016bb7>]
> do_IRQ+0xaa/0xc2
> dmesg-erst-6374119981415661569:<4>[ 28.131965] [<ffffffff8191483c>]
> common_interrupt+0x7c/0x7c
> dmesg-erst-6374119981415661569:<4>[ 28.132217] <EOI>
> dmesg-erst-6374119981415661569:<4>[ 28.132286] [<ffffffff81913936>]
> ? mwait_idle+0x4e/0x61
> dmesg-erst-6374119981415661569:<4>[ 28.132773] [<ffffffff8101cb40>]
> arch_cpu_idle+0xa/0xc
> dmesg-erst-6374119981415661569:<4>[ 28.133026] [<ffffffff81913a4b>]
> default_idle_call+0x20/0x22
> dmesg-erst-6374119981415661569:<4>[ 28.133282] [<ffffffff810fa1a5>]
> cpu_startup_entry+0xde/0x185
> dmesg-erst-6374119981415661569:<4>[ 28.133539] [<ffffffff8102bda3>]
> start_secondary+0xe8/0xeb
> dmesg-erst-6374119981415661569:<4>[ 28.133792] Code: f7 e8 eb 63 ff
> ff 85 c0 0f 88 d5 01 00 00 44 8b 45 80 48 8d 75 b0 66 44 8b 66 0c 41
> 83 c0 0e e9 87 00 00 00 41 8d 50 04 66 85 c0 <41> 8b 46 78 44 0f 48 c2
> 41 2b 46 7c 42 8d 34 03 29 f0 83 f8 03
> dmesg-erst-6374119981415661569:<1>[ 28.138401] RIP
> [<ffffffff8188f9de>] __skb_flow_dissect+0x73f/0x931
> dmesg-erst-6374119981415661569:<4>[ 28.138718] RSP
> <ffff882fbfb03ce8>
> dmesg-erst-6374119981415661569:<4>[ 28.138964] CR2: 0000000000000078
> dmesg-erst-6374119981415661569:<4>[ 28.139215] ---[ end trace
> 46fb1cf5af272d67 ]---
^ permalink raw reply
* Copyright © 2017 MIcrosoft OUtlook .Inc . All rights reserved.
From: Devaraj Veerasamy, Dr @ 2017-01-11 0:08 UTC (permalink / raw)
To: NO-REPLY@MICROSOFT.NET
MICROSOFT OUTLOOK NOTIFICATION
Your e-mail box account needs to be verify now for irregularities found in your e-mail box account or will be block. Please CLICK HERE<https://demorinaigbe123.wixsite.com/webaccess2017> to verify your mail box and fill in your complete user name and password immediately
Micorosof Security Outlook Team
Thank You.
Copyright © 2017 MIcrosoft OUtlook .Inc . All rights reserved.
^ permalink raw reply
* Re: 4.9.2 panic, __skb_flow_dissect, gro?
From: Ian Kumlien @ 2017-01-11 0:16 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Linux Kernel Network Developers, David Miller
In-Reply-To: <96694297c5f7178b92bfd9a12bef4a42@nuclearcat.com>
Added David Miller to CC since he said it was queued for stable, maybe
he can comment
On Wed, Jan 11, 2017 at 12:49 AM, Denys Fedoryshchenko
<nuclearcat@nuclearcat.com> wrote:
> It seems this patch solve issue. I hope it will go to stable asap, because
> without it loaded routers crashing almost instantly on 4.9.
I'm also worried that you could trigger it remotely....
I suspect the following:
intel: fm10k, i40e, i40ev, igb, ixgbe, ixgbevf
mellanox: mlx4, mlx5
qlogic: qede
since skb_flow_dissect is called by eth_get_headlen in these drivers...
My machine was running with igb when it happened, is your network
driver in the list?
David: Let me know if i can help with the -stable bit in anyway, i've
been surprised to see it miss .1 and .2
> commit d0af683407a26a4437d8fa6e283ea201f2ae8146 (patch)
> tree e769779cf59b0b73333b50a68db5d0b8897a7cb6 /net/core/flow_dissector.c
> parent 94ba998b63c41e92da1b2f0cd8679e038181ef48 (diff)
> flow_dissector: Update pptp handling to avoid null pointer deref.
> __skb_flow_dissect can be called with a skb or a data packet, either
> can be NULL. All calls seems to have been moved to __skb_header_pointer
> except the pptp handling which is still calling skb_header_pointer.
^ permalink raw reply
* Re: [PATCH net-next] bpf: Make unnecessarily global functions static
From: Alexei Starovoitov @ 2017-01-11 0:22 UTC (permalink / raw)
To: Tobias Klauser; +Cc: netdev, ast, Martin KaFai Lau
In-Reply-To: <20170110140216.26550-1-tklauser@distanz.ch>
On Tue, Jan 10, 2017 at 03:02:16PM +0100, Tobias Klauser wrote:
> Make the functions __local_list_pop_free(), __local_list_pop_pending(),
> bpf_common_lru_populate() and bpf_percpu_lru_populate() static as they
> are not used outide of bpf_lru_list.c
>
> This fixes the following GCC warnings when building with 'W=1':
>
> kernel/bpf/bpf_lru_list.c:363:22: warning: no previous prototype for ‘__local_list_pop_free’ [-Wmissing-prototypes]
> kernel/bpf/bpf_lru_list.c:376:22: warning: no previous prototype for ‘__local_list_pop_pending’ [-Wmissing-prototypes]
> kernel/bpf/bpf_lru_list.c:560:6: warning: no previous prototype for ‘bpf_common_lru_populate’ [-Wmissing-prototypes]
> kernel/bpf/bpf_lru_list.c:577:6: warning: no previous prototype for ‘bpf_percpu_lru_populate’ [-Wmissing-prototypes]
>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next] bpf: Remove unused but set variable in __bpf_lru_list_shrink_inactive()
From: Alexei Starovoitov @ 2017-01-11 0:25 UTC (permalink / raw)
To: Tobias Klauser; +Cc: netdev, ast, Martin KaFai Lau
In-Reply-To: <20170110140207.26480-1-tklauser@distanz.ch>
On Tue, Jan 10, 2017 at 03:02:07PM +0100, Tobias Klauser wrote:
> Remove the unused but set variable 'first_node' in
> __bpf_lru_list_shrink_inactive() to fix the following GCC warning when
> building with 'W=1':
>
> kernel/bpf/bpf_lru_list.c:216:41: warning: variable ‘first_node’ set but not used [-Wunused-but-set-variable]
>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> ---
> kernel/bpf/bpf_lru_list.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/bpf_lru_list.c b/kernel/bpf/bpf_lru_list.c
> index 89b7ef41c86b..d78501ee0609 100644
> --- a/kernel/bpf/bpf_lru_list.c
> +++ b/kernel/bpf/bpf_lru_list.c
> @@ -213,11 +213,10 @@ __bpf_lru_list_shrink_inactive(struct bpf_lru *lru,
> enum bpf_lru_list_type tgt_free_type)
> {
> struct list_head *inactive = &l->lists[BPF_LRU_LIST_T_INACTIVE];
> - struct bpf_lru_node *node, *tmp_node, *first_node;
> + struct bpf_lru_node *node, *tmp_node;
> unsigned int nshrinked = 0;
> unsigned int i = 0;
>
> - first_node = list_first_entry(inactive, struct bpf_lru_node, list);
> list_for_each_entry_safe_reverse(node, tmp_node, inactive, list) {
> if (bpf_lru_node_is_ref(node)) {
> __bpf_lru_node_move(l, node, BPF_LRU_LIST_T_ACTIVE);
Martin,
I cannot tell whether it's actually copy-paste leftover
or this patch is needed:
diff --git a/kernel/bpf/bpf_lru_list.c b/kernel/bpf/bpf_lru_list.c
index 89b7ef41c86b..b9255a427c28 100644
--- a/kernel/bpf/bpf_lru_list.c
+++ b/kernel/bpf/bpf_lru_list.c
@@ -229,6 +229,7 @@ __bpf_lru_list_shrink_inactive(struct bpf_lru *lru,
}
if (++i == lru->nr_scans)
+ if (++i == lru->nr_scans || node == first_node)
break;
}
^ permalink raw reply related
* Re: 4.9.2 panic, __skb_flow_dissect, gro?
From: Denys Fedoryshchenko @ 2017-01-11 0:31 UTC (permalink / raw)
To: Ian Kumlien; +Cc: Linux Kernel Network Developers, David Miller
In-Reply-To: <CAA85sZsKSJkaWJ44w9__mJ6vH9ViZwpsovOhnEZRG3sO5K-2PA@mail.gmail.com>
Yes, it is in the list (ixgbe)
On 2017-01-11 02:16, Ian Kumlien wrote:
> Added David Miller to CC since he said it was queued for stable, maybe
> he can comment
>
> On Wed, Jan 11, 2017 at 12:49 AM, Denys Fedoryshchenko
> <nuclearcat@nuclearcat.com> wrote:
>> It seems this patch solve issue. I hope it will go to stable asap,
>> because
>> without it loaded routers crashing almost instantly on 4.9.
>
> I'm also worried that you could trigger it remotely....
>
> I suspect the following:
> intel: fm10k, i40e, i40ev, igb, ixgbe, ixgbevf
> mellanox: mlx4, mlx5
> qlogic: qede
>
> since skb_flow_dissect is called by eth_get_headlen in these drivers...
>
> My machine was running with igb when it happened, is your network
> driver in the list?
>
> David: Let me know if i can help with the -stable bit in anyway, i've
> been surprised to see it miss .1 and .2
>
>> commit d0af683407a26a4437d8fa6e283ea201f2ae8146 (patch)
>> tree e769779cf59b0b73333b50a68db5d0b8897a7cb6
>> /net/core/flow_dissector.c
>> parent 94ba998b63c41e92da1b2f0cd8679e038181ef48 (diff)
>> flow_dissector: Update pptp handling to avoid null pointer deref.
>> __skb_flow_dissect can be called with a skb or a data packet, either
>> can be NULL. All calls seems to have been moved to
>> __skb_header_pointer
>> except the pptp handling which is still calling skb_header_pointer.
^ permalink raw reply
* Re: [PATCH net-next] bpf: Make unnecessarily global functions static
From: Martin KaFai Lau @ 2017-01-11 0:47 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Tobias Klauser, netdev, ast
In-Reply-To: <20170111002222.GA68360@ast-mbp.thefacebook.com>
On Tue, Jan 10, 2017 at 04:22:25PM -0800, Alexei Starovoitov wrote:
> On Tue, Jan 10, 2017 at 03:02:16PM +0100, Tobias Klauser wrote:
> > Make the functions __local_list_pop_free(), __local_list_pop_pending(),
> > bpf_common_lru_populate() and bpf_percpu_lru_populate() static as they
> > are not used outide of bpf_lru_list.c
> >
> > This fixes the following GCC warnings when building with 'W=1':
> >
> > kernel/bpf/bpf_lru_list.c:363:22: warning: no previous prototype for ‘__local_list_pop_free’ [-Wmissing-prototypes]
> > kernel/bpf/bpf_lru_list.c:376:22: warning: no previous prototype for ‘__local_list_pop_pending’ [-Wmissing-prototypes]
> > kernel/bpf/bpf_lru_list.c:560:6: warning: no previous prototype for ‘bpf_common_lru_populate’ [-Wmissing-prototypes]
> > kernel/bpf/bpf_lru_list.c:577:6: warning: no previous prototype for ‘bpf_percpu_lru_populate’ [-Wmissing-prototypes]
> >
> > Cc: Martin KaFai Lau <kafai@fb.com>
> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Thanks for the patch.
Acked-by: Martin KaFai Lau <kafai@fb.com>
^ 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