netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Kees Cook <keescook@chromium.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Subject: Re: ether_addr_equal_64bits breakage with gcc-12
Date: Sat, 12 Feb 2022 10:08:11 +0100	[thread overview]
Message-ID: <20220212090811.uuzk6d76agw2vv73@pengutronix.de> (raw)
In-Reply-To: <202202111642.EF22DF8BD@keescook>

[-- Attachment #1: Type: text/plain, Size: 2559 bytes --]

On 11.02.2022 17:31:22, Kees Cook wrote:
> > Maybe Kees will have as suggestion - Kees, are there any best practices
> > for dealing with such issues? For the reference we do a oversized load
> > from a structure (read 8B of a 6B array):
> 
> Wheee.
> 
> So, the short theoretical "don't do that" scenario would be "what
> happens if":
> 
>         struct page *page;
>         void *ptr;
> 	unsigned char *eth_addr;
> 
>         page = alloc_pages(GFP_KERNEL, 0);
> 	...
>         ptr = page_address(page);
> 	...
> 	/* "eth_addr" at end of allocated memory */
> 	eth_addr = ptr + PAGE_SIZE - 6;
> 	/* access fault... */
> 	ether_addr_equal_64bits(eth_addr, ...);
> 
> But, yes, pragmatically, this is likely extremely rare.
> 
> Regardless, with the other cases like this that got fixed like this, it
> was a matter of finding a way to represent the "actual" available memory
> (best), or telling the compiler what real contract is (less good).
> 
> It looks like alignment isn't a concern, so I'd say adjust the prototype
> to reflect the reality, and go with:
> 
> 
> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> index 2ad71cc90b37..92b10e67d5f8 100644
> --- a/include/linux/etherdevice.h
> +++ b/include/linux/etherdevice.h
> @@ -134,7 +134,7 @@ static inline bool is_multicast_ether_addr(const u8 *addr)
>  #endif
>  }
>  
> -static inline bool is_multicast_ether_addr_64bits(const u8 addr[6+2])
> +static inline bool is_multicast_ether_addr_64bits(const u8 *addr)
>  {
>  #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && BITS_PER_LONG == 64
>  #ifdef __BIG_ENDIAN
> @@ -372,8 +372,7 @@ static inline bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
>   * Please note that alignment of addr1 & addr2 are only guaranteed to be 16 bits.
>   */
>  
> -static inline bool ether_addr_equal_64bits(const u8 addr1[6+2],
> -					   const u8 addr2[6+2])
> +static inline bool ether_addr_equal_64bits(const u8 *addr1, const u8 *addr2)
>  {
>  #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && BITS_PER_LONG == 64
>  	u64 fold = (*(const u64 *)addr1) ^ (*(const u64 *)addr2);
> 

With that patch the warning is gone.

Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2022-02-12  9:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-11 14:12 ether_addr_equal_64bits breakage with gcc-12 Marc Kleine-Budde
2022-02-12  0:35 ` Jakub Kicinski
2022-02-12  1:31   ` Kees Cook
2022-02-12  9:08     ` Marc Kleine-Budde [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220212090811.uuzk6d76agw2vv73@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=keescook@chromium.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).