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 C8C2EC433EF for ; Tue, 22 Feb 2022 10:35:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230319AbiBVKgK (ORCPT ); Tue, 22 Feb 2022 05:36:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229501AbiBVKgJ (ORCPT ); Tue, 22 Feb 2022 05:36:09 -0500 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD5AB15B99E for ; Tue, 22 Feb 2022 02:35:42 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id u20so23856848lff.2 for ; Tue, 22 Feb 2022 02:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=+lVCwDiOku8kLSVJnTfKoIgYRuSLH77+xI/uMbyK9OA=; b=g42GYshzG9e6NElFaCS8Jefbr7OC5dly7FlECjdhp3xNpsCgJClndEfQTRjDb4e8u7 2jqdHuQ0aJKFx/7JdrgipgzJd3fTdqCpZ0f5/VE72oALWFrHqtBLylrIqUKokBuJmByw xSUNTd+M4uvzCWa91yZzcdnh5pqshAnihRmns= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=+lVCwDiOku8kLSVJnTfKoIgYRuSLH77+xI/uMbyK9OA=; b=Q+nLv22/nkKAQaXw/CN7IBRKtWzDwaCTeUO/GlsFmrVcNwTqHOpFLOy/5Qm2xpIgZT z2wwiaL68/x3PKZhuPl9okXF/YT3c24JPDKiaK8C6+aqo8Gma9FOSbSAueRW6pHwzVd+ 4gGIwRkne7TsxFmC+KcrNgMVGLuCNcUICpnxeJKNeD6bRCcoup/ux8lHjDcZefeZkwqI d2f6pgzFnJezSZMpjFjEtixFkPscz/AMb9nGyYAZ0GFi28sRdNlKG3gLbTGxOrEvCykz WUObadFlt/FrWXIXSHgEjJIZ0mCC9S/V71k3Q9uGhGxAh6+Zt/YEmO4lIGxHyXt+bweX PxOw== X-Gm-Message-State: AOAM532QnhSPWFS8bFYlu0ZJNbz6yJp9EiR0mb/qsFIU8TsLbNCmUeM0 q7ufGJt4eZNFGKk4HaSzbG2NBA== X-Google-Smtp-Source: ABdhPJw7mYLWWpMf+NUtglLOXRjELIKiJZkgSiolfEArK+dH1UUaX9aYYOXYyapKylfEHYLmtw7e6Q== X-Received: by 2002:ac2:46ef:0:b0:443:3c30:a372 with SMTP id q15-20020ac246ef000000b004433c30a372mr16966119lfo.626.1645526141133; Tue, 22 Feb 2022 02:35:41 -0800 (PST) Received: from [172.16.11.74] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id m7sm1638575ljb.87.2022.02.22.02.35.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Feb 2022 02:35:40 -0800 (PST) Message-ID: <10bbffc2-f144-8555-d41b-fede69a13c16@rasmusvillemoes.dk> Date: Tue, 22 Feb 2022 11:35:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v4 12/20] vsprintf: add new `%pA` format specifier Content-Language: en-US To: Petr Mladek , Miguel Ojeda Cc: Andy Shevchenko , Miguel Ojeda , Linus Torvalds , Greg Kroah-Hartman , rust-for-linux , linux-kernel , Gary Guo , Alex Gaynor , Wedson Almeida Filho , Steven Rostedt , Sergey Senozhatsky References: <20220212130410.6901-1-ojeda@kernel.org> <20220212130410.6901-13-ojeda@kernel.org> From: Rasmus Villemoes In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: rust-for-linux@vger.kernel.org On 22/02/2022 10.29, Petr Mladek wrote: > On Mon 2022-02-14 13:12:24, Miguel Ojeda wrote: >> On Mon, Feb 14, 2022 at 11:52 AM Rasmus Villemoes >> wrote: >>> >>> I think the point is for vsnprintf() to call (back) into Rust code. >> >> Indeed, this is the case. >> >>> That said, I don't like the !CONFIG_RUST version to return NULL, that >>> will surely crash moments later. >>> >>> So I prefer something like >>> >>> [rust.h] >>> // no CONFIG_RUST conditional >>> +char *rust_fmt_argument(char* buf, char* end, void *ptr); >>> >>> [vsprintf.c] >>> + case 'A': >>> + if (IS_ENABLED(CONFIG_RUST)) >>> + return rust_fmt_argument(buf, end, ptr); >>> + else >>> + return string_nocheck(buf, end, "[%pA in non-Rust >>> code?!]", default_str_spec); > > Any long message might cause buffer overflow when the caller expects > fixed short string. If the caller (1) uses a %p extension from C code which should only be used from Rust and (2) uses sprintf() or another variant where he doesn't provide the real buffer bounds, well, then he certainly gets to keep the pieces. It is a much worse problem that if CONFIG_RUST is enabled, we can't know that we were actually called from Rust (but when !CONFIG_RUST, we certainly know that we weren't), so we could call into rust_fmt_argument with a pointer which certainly doesn't point to the/a data structure which that Rust code expects. But we can't do anything about it, we will just have to rely on static analysis to flag any use of %pA in C code. > The most safe solution would be to use WARN_ONCE(). Preferably no, we shouldn't call into the printk machinery from within vsnprintf(). I know I've added a few myself (AFAIR for use of %n or other unsupported specifiers, and for overflow of precision/field width), and I've often thought about a way to get rid of them while still making sure some message eventually gets logged (once). Rasmus