linux-kernel - Re: [PATCH 4.19 36/55] drivers/net/b44: Change to non-atomic bit operations on pwol

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:   Fri, 31 Jan 2020 13:57:31 +0100
From:   Pavel Machek <pavel@...x.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 36/55] drivers/net/b44: Change to non-atomic bit
 operations on pwol_mask

On Thu 2020-01-30 19:39:17, Greg Kroah-Hartman wrote:
> From: Fenghua Yu <fenghua.yu@...el.com>
> 
> [ Upstream commit f11421ba4af706cb4f5703de34fa77fba8472776 ]

This is not suitable for stable. It does not fix anything. It prepares
for theoretical bug that author claims might be introduced to BIOS in
future... I doubt it, even BIOS authors boot their machines from time
to time.

> Atomic operations that span cache lines are super-expensive on x86
> (not just to the current processor, but also to other processes as all
> memory operations are blocked until the operation completes). Upcoming
> x86 processors have a switch to cause such operations to generate a #AC
> trap. It is expected that some real time systems will enable this mode
> in BIOS.

And I wonder if this is even good idea for mainline. x86 architecture
is here for long time, and I doubt Intel is going to break it like
this. Do you have documentation pointer? 

> In preparation for this, it is necessary to fix code that may execute
> atomic instructions with operands that cross cachelines because the #AC
> trap will crash the kernel.

How does single bit operation "cross cacheline"? How is this going to
impact non-x86 architectures?

> Since "pwol_mask" is local and never exposed to concurrency, there is
> no need to set bits in pwol_mask using atomic operations.
> 
> Directly operate on the byte which contains the bit instead of using
> __set_bit() to avoid any big endian concern due to type cast to
> unsigned long in __set_bit().

What concerns? Is __set_bit() now useless and are we going to open-code
it everywhere? Is set_bit() now unusable on x86?
								
								Pavel
								
> Suggested-by: Peter Zijlstra <peterz@...radead.org>
> Signed-off-by: Fenghua Yu <fenghua.yu@...el.com>
> Signed-off-by: Tony Luck <tony.luck@...el.com>
> Signed-off-by: David S. Miller <davem@...emloft.net>
> Signed-off-by: Sasha Levin <sashal@...nel.org>
> ---
>  drivers/net/ethernet/broadcom/b44.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/b44.c b/drivers/net/ethernet/broadcom/b44.c
> index e445ab724827f..88f8d31e4c833 100644
> --- a/drivers/net/ethernet/broadcom/b44.c
> +++ b/drivers/net/ethernet/broadcom/b44.c
> @@ -1519,8 +1519,10 @@ static int b44_magic_pattern(u8 *macaddr, u8 *ppattern, u8 *pmask, int offset)
>  	int ethaddr_bytes = ETH_ALEN;
>  
>  	memset(ppattern + offset, 0xff, magicsync);
> -	for (j = 0; j < magicsync; j++)
> -		set_bit(len++, (unsigned long *) pmask);
> +	for (j = 0; j < magicsync; j++) {
> +		pmask[len >> 3] |= BIT(len & 7);
> +		len++;
> +	}
>  
>  	for (j = 0; j < B44_MAX_PATTERNS; j++) {
>  		if ((B44_PATTERN_SIZE - len) >= ETH_ALEN)
> @@ -1532,7 +1534,8 @@ static int b44_magic_pattern(u8 *macaddr, u8 *ppattern, u8 *pmask, int offset)
>  		for (k = 0; k< ethaddr_bytes; k++) {
>  			ppattern[offset + magicsync +
>  				(j * ETH_ALEN) + k] = macaddr[k];
> -			set_bit(len++, (unsigned long *) pmask);
> +			pmask[len >> 3] |= BIT(len & 7);
> +			len++;
>  		}
>  	}
>  	return len - 1;
> -- 
> 2.20.1
> 
> 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)