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 X-Spam-Level: X-Spam-Status: No, score=-8.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 245F0C43387 for ; Wed, 16 Jan 2019 17:00:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DF07A20859 for ; Wed, 16 Jan 2019 17:00:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Lp8LYaUC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391346AbfAPRA4 (ORCPT ); Wed, 16 Jan 2019 12:00:56 -0500 Received: from mail-vs1-f66.google.com ([209.85.217.66]:45830 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391337AbfAPRA4 (ORCPT ); Wed, 16 Jan 2019 12:00:56 -0500 Received: by mail-vs1-f66.google.com with SMTP id x28so4322015vsh.12 for ; Wed, 16 Jan 2019 09:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UEMunj8ChcDFCPVv56ZqfkQzOLzqlwJANgzHniDiVk4=; b=Lp8LYaUCRX0x/1u2daorpvaRrd1f1nCVB2earXJRajh6HVH/Fn7lDSXVdUQUWjDI0/ oCUX9nPgENRUq2jhW8e4iqaviCekY5zdfBo5cmup47g0dGJkWQFQfYifCCAvB8T6IEiu cZvdrf5cT2/qq1Mh3z2sx0dymUqxiIvs+WjR4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UEMunj8ChcDFCPVv56ZqfkQzOLzqlwJANgzHniDiVk4=; b=GdwaIItZxiXiDv/cI/GbPFanSuJNpizmK9RLfuZmutw3ojWQzfbzvBXVdwWtsPjrR+ K65+QQ/usb3qPDhiDAuadJrP2LCyRtiuZ+sRxkOrS9/tiBQtW4dfIxTLasEOu/oNBgh5 Qu1bhMz7I44+GLnVYvV9f3miawpUG0YouZmOAHjdn7lUXLTkSqhJ5qlm9LLhQTr4Fw8h ny/VY1x49en3bXMUlfSVU2jZUmCh29qaoZUnMwZwxVVKSxOoC+34U+589N7Tjq9IEY8Z DPLeP2RnG9WjVD3Dy8p3M32+DIYSW+2d2wc7buE2XKeaXm/CH/VPwLzC/geNywkW2Qkh qsTQ== X-Gm-Message-State: AJcUukdGozaTRj9lxZxkKnNW3ASEnEcT55/UuJ6hee9Jh5tRAMxlI/RL 1Z3e6rROU9pjfnLFQXZ7vU70c1jzqhM= X-Google-Smtp-Source: ALg8bN4EC44LDJnSSIE7J3D7RgI5e1TkBORD/7fypMTkQe5aY8WtjvU94AfU3c24Ev81Qt8o2WEB4Q== X-Received: by 2002:a67:8291:: with SMTP id e139mr4231003vsd.3.1547658054348; Wed, 16 Jan 2019 09:00:54 -0800 (PST) Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com. [209.85.217.41]) by smtp.gmail.com with ESMTPSA id q193sm7512284vsd.0.2019.01.16.09.00.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Jan 2019 09:00:53 -0800 (PST) Received: by mail-vs1-f41.google.com with SMTP id p74so4384241vsc.0 for ; Wed, 16 Jan 2019 09:00:53 -0800 (PST) X-Received: by 2002:a67:848a:: with SMTP id g132mr4079226vsd.222.1547658052420; Wed, 16 Jan 2019 09:00:52 -0800 (PST) MIME-Version: 1.0 References: <20190114181336.74501-1-gwendal@chromium.org> <20190114185040.GB13821@kroah.com> In-Reply-To: From: Kees Cook Date: Wed, 16 Jan 2019 09:00:39 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] proc: Remove empty line in /proc/self/status To: Guenter Roeck Cc: Greg Kroah-Hartman , Gwendal Grignou , "# v4 . 10+" , Guenter Roeck Content-Type: text/plain; charset="UTF-8" Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Wed, Jan 16, 2019 at 8:06 AM Guenter Roeck wrote: > > On Mon, Jan 14, 2019 at 11:05 AM Kees Cook wrote: > > > > On Mon, Jan 14, 2019 at 11:01 AM Guenter Roeck wrote: > > > > > > On Mon, Jan 14, 2019 at 10:50 AM Greg Kroah-Hartman > > > wrote: > > > > > > > > On Mon, Jan 14, 2019 at 10:21:45AM -0800, Guenter Roeck wrote: > > > > > On Mon, Jan 14, 2019 at 10:13 AM Gwendal Grignou wrote: > > > > > > > > > > > > Prevent an empty line in /proc/self/status, allow iotop to work. > > > > > > > > > > > > iotop does not like empty lines, fails with: > > > > > > File "/usr/local/lib64/python2.7/site-packages/iotop/data.py", line > > > > > > 196, in parse_proc_pid_status > > > > > > key, value = line.split(':\t', 1) > > > > > > ValueError: need more than 1 value to unpack > > > > > > > > > > > > [reading /proc/self/status] > > > > > > > > > > > > Fixes: 84964fa3e5a0 ("proc: Provide details on speculation flaw mitigations") > > > > > > > > > > > > Signed-off-by: Gwendal Grignou > > > > > > --- > > > > > > v2: Format commit message properly with proper subject and fixes > > > > > > keyword. > > > > > > > > > > > You might want to mention that this patch only applies to v4.4.y. > > > > > v4.9.y has a similar problem, but only if CONFIG_SECCOMP=n, and would > > > > > require a slightly different patch to fix. Other releases are, as far > > > > > as I can see, not affected. > > > > > > > > > > Guenter > > > > > > > > > > > fs/proc/array.c | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/fs/proc/array.c b/fs/proc/array.c > > > > > > index 0c142916a8c7d..f11df9ab4256e 100644 > > > > > > --- a/fs/proc/array.c > > > > > > +++ b/fs/proc/array.c > > > > > > @@ -334,7 +334,7 @@ static inline void task_seccomp(struct seq_file *m, struct task_struct *p) > > > > > > #ifdef CONFIG_SECCOMP > > > > > > seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode); > > > > > > #endif > > > > > > - seq_printf(m, "\nSpeculation_Store_Bypass:\t"); > > > > > > + seq_printf(m, "Speculation_Store_Bypass:\t"); > > > > > > > > Why isn't this issue showing up in all kernel releases, as this line is > > > > still the same in 5.0-rc2? > > > > > > > > What makes the 4.4.y and 4.9.y trees so special here? > > > > > > > > > > v4.14 and later: > > > > > > { > > > seq_put_decimal_ull(m, "NoNewPrivs:\t", task_no_new_privs(p)); > > > #ifdef CONFIG_SECCOMP > > > seq_put_decimal_ull(m, "\nSeccomp:\t", p->seccomp.mode); > > > #endif > > > seq_printf(m, "\nSpeculation_Store_Bypass:\t"); > > > > > > --- > > > v4.9: > > > > > > { > > > #ifdef CONFIG_SECCOMP > > > seq_put_decimal_ull(m, "Seccomp:\t", p->seccomp.mode); > > > ^^^ > > > #endif > > > seq_printf(m, "\nSpeculation_Store_Bypass:\t"); > > > ^^^ > > > > > > -> extra newline if CONFIG_SECCOMP=n > > > > > > --- > > > v4.4: > > > > > > { > > > #ifdef CONFIG_SECCOMP > > > seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode); > > > ^^^ > > > #endif > > > seq_printf(m, "\nSpeculation_Store_Bypass:\t"); > > > ^^^ > > > > > > -> always extra newline > > > > > > Guenter > > > > Yeah, this grew out of odd placement of the trailing "\n". I agree it > > needs fixing universally. > > > > I think we need some guidance on how to fix this problem in 4.4.y and > 4.9.y. Backport more of the context patches or stable-release-only > patches, possibly with more context explaining the reason ? I think we need 4.4 and 4.9 specific patches that fix it up, and a patch to Linus that regularizes the "always have a trailing \n" style (since the mixture of newlines was what causes this problem in the first place). -- Kees Cook