netdev - Re: [PATCH net-next v2 6/6] net: qualcomm: rmnet: don't use C bit-fields in rmnet checksum header

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 8 Mar 2021 07:59:20 -0600
From:   Alex Elder <elder@...aro.org>
To:     David Laight <David.Laight@...LAB.COM>,
        "subashab@...eaurora.org" <subashab@...eaurora.org>,
        "stranche@...eaurora.org" <stranche@...eaurora.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>
Cc:     "sharathv@...eaurora.org" <sharathv@...eaurora.org>,
        "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
        "evgreen@...omium.org" <evgreen@...omium.org>,
        "cpratapa@...eaurora.org" <cpratapa@...eaurora.org>,
        "elder@...nel.org" <elder@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        kernel test robot <lkp@...el.com>
Subject: Re: [PATCH net-next v2 6/6] net: qualcomm: rmnet: don't use C
 bit-fields in rmnet checksum header

On 3/8/21 4:18 AM, David Laight wrote:
> From: Alex Elder
>> Sent: 06 March 2021 03:16
>>
>> Replace the use of C bit-fields in the rmnet_map_ul_csum_header
>> structure with a single two-byte (big endian) structure member,
>> and use field masks to encode or get values within it.
>>
>> Previously rmnet_map_ipv4_ul_csum_header() would update values in
>> the host byte-order fields, and then forcibly fix their byte order
>> using a combination of byte order operations and types.
>>
>> Instead, just compute the value that needs to go into the new
>> structure member and save it with a simple byte-order conversion.
>>
>> Make similar simplifications in rmnet_map_ipv6_ul_csum_header().
>>
>> Finally, in rmnet_map_checksum_uplink_packet() a set of assignments
>> zeroes every field in the upload checksum header.  Replace that with
>> a single memset() operation.
>>
>> Signed-off-by: Alex Elder <elder@...aro.org>
>> Reported-by: kernel test robot <lkp@...el.com>
>> ---
>> v2: Fixed to use u16_encode_bits() instead of be16_encode_bits().
>>
>>   .../ethernet/qualcomm/rmnet/rmnet_map_data.c  | 34 ++++++-------------
>>   include/linux/if_rmnet.h                      | 21 ++++++------
>>   2 files changed, 21 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
>> b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
>> index 29d485b868a65..b76ad48da7325 100644
>> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
>> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
>> @@ -198,23 +198,19 @@ rmnet_map_ipv4_ul_csum_header(void *iphdr,
>>   			      struct rmnet_map_ul_csum_header *ul_header,
>>   			      struct sk_buff *skb)
>>   {
>> -	__be16 *hdr = (__be16 *)ul_header;
>>   	struct iphdr *ip4h = iphdr;
>>   	u16 offset;
>> +	u16 val;
>>
>>   	offset = skb_transport_header(skb) - (unsigned char *)iphdr;
>>   	ul_header->csum_start_offset = htons(offset);
>>
>> -	ul_header->csum_insert_offset = skb->csum_offset;
>> -	ul_header->csum_enabled = 1;
>> +	val = u16_encode_bits(1, MAP_CSUM_UL_ENABLED_FMASK);
>>   	if (ip4h->protocol == IPPROTO_UDP)
>> -		ul_header->udp_ind = 1;
>> -	else
>> -		ul_header->udp_ind = 0;
>> +		val |= u16_encode_bits(1, MAP_CSUM_UL_UDP_FMASK);
>> +	val |= u16_encode_bits(skb->csum_offset, MAP_CSUM_UL_OFFSET_FMASK);
>>
>> -	/* Changing remaining fields to network order */
>> -	hdr++;
>> -	*hdr = htons((__force u16)*hdr);
>> +	ul_header->csum_info = htons(val);
> 
> Isn't this potentially misaligned?

At first I thought you were talking about column alignment.

The short answer:  Yes (at least it's possible)!  And
that's a problem elsewhere in the driver.  I noticed
that before and confirmed that unaligned accesses *do*
occur in this driver.

I would want to fix that comprehensively (and separate
from this patch), and not just in this one spot.  I have
not done it because I am not set up to readily test the
change; unaligned access does not cause a fault on aarch64
(or at least on the platforms I'm using).

Sort of related, I have been meaning to eliminate the
pointless __aligned(1) tags on rmnet structures defined
in <linux/if_rmnet.h>.  It wouldn't hurt to use __packed,
though I think they're all 4 or 8 bytes naturally anyway.
Perhaps marking them __aligned(4) would help identify
potential unaligned accesses?

Anyway, assuming you're not talking about tab stops, yes
it's possible this assignment is misaligned.  But it's a
bigger problem than what you point out.  I will take this
as a sign that I'm not the only one who has this concern,
meaning I should maybe bump the priority on getting this
alignment thing fixed.

					-Alex

> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>