From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27A33ECAAA3 for ; Fri, 26 Aug 2022 07:40:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245406AbiHZHko (ORCPT ); Fri, 26 Aug 2022 03:40:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245391AbiHZHk0 (ORCPT ); Fri, 26 Aug 2022 03:40:26 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4FF6D6E2C1 for ; Fri, 26 Aug 2022 00:40:24 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id l1so936387lfk.8 for ; Fri, 26 Aug 2022 00:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=SWG+AYYaD3CGqVmhJUkc0npDBvTLvT/qXBQNeQdRPPI=; b=VavM614ow0Wq5WTGNBaTek9R2gSqCSK2LowLKioZCjH9fi0rLESL9gU51h6u1ICdVM O54wO0xGy8NLlu+JxKeFrsTK5D6TMHGLwWPXbcToifiej4CvHspsXtqeC5ShKEruaDem 2VWI9zZ+ad+AeT/jOq3cAhJOGxL7TuGKXf1GA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=SWG+AYYaD3CGqVmhJUkc0npDBvTLvT/qXBQNeQdRPPI=; b=GUeeorSulJImJiE3t3m1x/YddzNlOuX1Lshzuugcwylwbf4M+pzRD4610mmqkJjAow M/zlFioXcBEHj1rs5LgAi96R9x39v35jkrioc7nVrYCbAEISwxW7SrVGgzHx8m2xs2KI cY4RXL4y5RdBcNJ+r+1P3sIab86qXe/lVjI9BkYLJJ/X/yJBtrZzzot+2rxChQPw1/9h kOwYLr5O1BNj6SCa79wLTvCU2Zejf9ns5UG9aiuVnX1jAEH6eTgpYqzle30x6cbG1ON6 bsB+YI1O2jLRMpmtQrwYE+PqTInl+PIh7APSdQl2Cuv0bqr9RJ268yWNQjeeqTelaQEX ii0g== X-Gm-Message-State: ACgBeo1Nx7in7Dt/7RRaJfbB9xtKdiRUYDwf1Vkufow+IG/39lo5X8+p /+9/UciWkbxBzBMh62U1Fw8lmJrCO/mvB2NB X-Google-Smtp-Source: AA6agR5Wm1zWSG4SC+mpBPzTyeIPT/0fZuyJYI07D9p9QGCLhhs/GEofhI1B8Us/Ffey/8A1d/hh1Q== X-Received: by 2002:a19:645c:0:b0:492:cf78:62de with SMTP id b28-20020a19645c000000b00492cf7862demr1925671lfj.263.1661499622588; Fri, 26 Aug 2022 00:40:22 -0700 (PDT) Received: from [172.16.11.74] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id q15-20020ac24a6f000000b0048b3926351bsm293857lfp.56.2022.08.26.00.40.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Aug 2022 00:40:21 -0700 (PDT) Message-ID: <527eee19-532f-b2e7-a42f-a1e199094fbe@rasmusvillemoes.dk> Date: Fri, 26 Aug 2022 09:40:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: strlcpy() notes (was Re: [GIT PULL] smb3 client fixes) Content-Language: en-US To: Linus Torvalds , Catalin Marinas Cc: Steve French , CIFS , LKML , linux-arch References: From: Rasmus Villemoes In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/08/2022 19.37, Linus Torvalds wrote: > On Tue, Aug 23, 2022 at 1:56 AM Catalin Marinas wrote: >> >> With load_unaligned_zeropad(), the arm64 implementation disables tag >> checking temporarily. We could do the same with read_word_at_a_time() >> (there is a kasan_check_read() in this function but it wrongly uses a >> size of 1). > > The "size of 1" is not wrong, it's intentional, exactly because people > do things like > > strscpy(dst, "string", sizeof(dst)); > > which is a bit unfortunate, but very understandable and intended to > work. So that thing may over-read the string by up to a word. And > KASAN ends up being unhappy. So, while we're doing all the churn of replacing strlcpy anyway, may I once again suggest we add (name can be bikeshedded) literal_strcpy(): #define literal_strcpy(d, s) ({ \ static_assert(__same_type(d, char[]), "destination must be char array"); \ static_assert(__same_type(s, const char[]), "source must be a string literal"); \ static_assert(sizeof(d) >= sizeof("" s ""), "source does not fit in destination"); \ strcpy(d, s); \ }) That interface _cannot_ be misused, because all the checking happens at build time, including enforcement that the source really is a string literal (the "" s "" trick - but for nicer error message the static_assert on the previous line is there as well). So unlike all the uses of str[ls]cpy which don't check the return value, we cannot silently do a truncated copy. Also, if somebody down the line changes the size of the destination or the literal string, again it will be caught at build time. And since gcc knows the semantics of strcpy(), it will also generate better code, because it will usually not emit a call at all (or even put the string in .rodata); it will simply emit a series of "mov immediate" instructions. Sloppy grepping for places where that could be used shows around ~800 places. Btw, Steve, since you're incidentally on cc here anyway, perhaps you want to take a look at strscpy(extension, "___", strlen("___")); and see if this really just wants two underscores copied to extension. Rasmus