lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20161206.114356.2137355703606265376.davem@davemloft.net>
Date:   Tue, 06 Dec 2016 11:43:56 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     salil.mehta@...wei.com
Cc:     yisen.zhuang@...wei.com, mehta.salil.lnk@...il.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        linuxarm@...wei.com
Subject: Re: [PATCH V4 net-next] net: hns: Fix to conditionally convey RX
 checksum flag to stack

From: Salil Mehta <salil.mehta@...wei.com>
Date: Tue, 6 Dec 2016 11:09:46 +0000

> This patch introduces the RX checksum function to check the
> status of the hardware calculated checksum and its error and
> appropriately convey status to the upper stack in skb->ip_summed
> field.
> 
> In hardware, we only support checksum for the following
> protocols:
> 1) IPv4,
> 2) TCP(over IPv4 or IPv6),
> 3) UDP(over IPv4 or IPv6),
> 4) SCTP(over IPv4 or IPv6)
> but we support many L3(IPv4, IPv6, MPLS, PPPoE etc) and
> L4(TCP, UDP, GRE, SCTP, IGMP, ICMP etc.) protocols.
> 
> Hardware limitation:
> Our present hardware RX Descriptor lacks L3/L4 checksum
> "Status & Error" bit (which usually can be used to indicate whether
> checksum was calculated by the hardware and if there was any error
> encountered during checksum calculation).
> 
> Software workaround:
> We do get info within the RX descriptor about the kind of
> L3/L4 protocol coming in the packet and the error status. These
> errors might not just be checksum errors but could be related to
> version, length of IPv4, UDP, TCP etc.
> Because there is no-way of knowing if it is a L3/L4 error due
> to bad checksum or any other L3/L4 error, we will not (cannot)
> convey hardware checksum status(CHECKSUM_UNNECESSARY) for such
> cases to upper stack and will not maintain the RX L3/L4 checksum
> counters as well.
> 
> Signed-off-by: Salil Mehta <salil.mehta@...wei.com>

Applied.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ