Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] proc: Disable /proc/$pid/wchan
To:     Kees Cook <keescook@chromium.org>,
        Thomas Gleixner <tglx@linutronix.de>
Cc:     Josh Poimboeuf <jpoimboe@redhat.com>,
        Vito Caputo <vcaputo@pengaru.com>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>, Jens Axboe <axboe@kernel.dk>,
        Mark Rutland <mark.rutland@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Stefan Metzmacher <metze@samba.org>,
        Andy Lutomirski <luto@kernel.org>,
        Lai Jiangshan <laijs@linux.alibaba.com>,
        Christian Brauner <christian.brauner@ubuntu.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Kenta.Tada@sony.com" <Kenta.Tada@sony.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        =?UTF-8?Q?Michael_Wei=c3=9f?= <michael.weiss@aisec.fraunhofer.de>,
        Anand K Mistry <amistry@google.com>,
        Alexey Gladkov <legion@kernel.org>,
        Michal Hocko <mhocko@suse.com>, Helge Deller <deller@gmx.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andrea Righi <andrea.righi@canonical.com>,
        Ohhoon Kwon <ohoono.kwon@samsung.com>,
        Kalesh Singh <kaleshsingh@google.com>,
        YiFei Zhu <yifeifz2@illinois.edu>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        linux-fsdevel@vger.kernel.org, linux-hardening@vger.kernel.org
References: <20210923233105.4045080-1-keescook@chromium.org>
From:   Stephen Brennan <stephen.s.brennan@oracle.com>
Message-ID: <c283c978-2563-06b9-4c21-59bedceda9ea@oracle.com>
Date:   Thu, 30 Sep 2021 11:05:35 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
In-Reply-To: <20210923233105.4045080-1-keescook@chromium.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YU8yRW1HcHVmNGI1M0xOVVlpTTVlVkhscVdHNjdoeWgyTFRXUzhGN0ZmV2Fh?=
 =?utf-8?B?Vm11TXRreGRMc28zTk56R2xmVTdpNGFEcDVPYkxRVmNIeXpvT2l2SzZvQVRk?=
 =?utf-8?B?cVVBeFlhOFVFVElCU2UxcExFb1RoMHAvak9IWGJ0ZmFpMmNncjhMWEx3WDdz?=
 =?utf-8?B?MjBRQW9mcTJhY1QzN0kxRlIwU0NTQ3hMcitzN0MzQmxwSHhMUXA1UGdmR055?=
 =?utf-8?B?MUd6eXRZOFJuOENIRmhDZS9FQWdsZVFqSGJjam4wQ3dTRnFyVURSNVhGQWlm?=
 =?utf-8?B?UnFXVjB5SE9DaUFwbDJJa21UTDdnK2ttOWpuSzN0Q21Uc2lxVkZqaVRKYU5a?=
 =?utf-8?B?NTdhbzMrS2dSZVhEVzVFb0JiR290RU5VZHNCOGxNa1h5WGRuLzVLRUIrWFNo?=
 =?utf-8?B?ODMxT1R5dFJ3bEMzZ1Z0RXUvMi9lYVNUMVJUWVJKWUw2S2hHWi9qVFFlVkRF?=
 =?utf-8?B?Qm51NEgvRzJnRk5RQUhLNklpYkZxTlN1OW05K0RFZ0VMSVo2WlpmZFhHYVBR?=
 =?utf-8?B?Z25MMHlqTEkzZ0R3alZHbWpCL2pSU3lHNExUMndvQmdhKzZyK2ZsREFrY3JM?=
 =?utf-8?B?VXM4WFlpNmh5RmFEeTh4RE1icS83UDhPN3FoUnlCOEx1ajBraGJaWHN5ZmNI?=
 =?utf-8?B?VWxtRzVoT0ZaRHVuRGRSaFZNSWN5QVN0VmFIcExoSVFwUThaYnljODVUdTU1?=
 =?utf-8?B?bEdkN3cwd0x2NWErYVlNYk4yYkRqUzJMZ3ppL2hxQnNEbmViUi9ubDN0WW9E?=
 =?utf-8?B?VFhpb29tbHp4UGVsK2JsRDdNSG9MbHM1Z0F6ZXpaTDBtc2F3YkFyRDhqZlFN?=
 =?utf-8?B?UkFsUTlxb250a2ZJVTdRWFJBMzhrc0kzNlVrQmhFL28vRTFYaDNlL2poamlE?=
 =?utf-8?B?enNKaDRZL0JVb0dSUXhEZldNZVFPMjBrNDdmbzVoMnBxS0ZWUjkwYk5YeE8v?=
 =?utf-8?B?V3ZKc09HTmJZbmlNVEMrZFFnTkdwc0krU1EveTRLWWhGTUwxWE1NemxiNVRo?=
 =?utf-8?B?S0FQYW16YjVNZnFqa1R0L21MTlRpTlZpejNjK01kR2RvMUhMekNKa0ppUGtX?=
 =?utf-8?B?TmptZnRDWFMyRFlaVVkrL1VwVmZ5TmFtdHpuczBUcVVwL2Z0NDVhOWFsTkdk?=
 =?utf-8?B?djIwREtFT0RIRTh4SEJzcjBiSmVRaUhZcXFMdFJtNFd2ODhtbXBJcDJtZzMv?=
 =?utf-8?B?UjgxNm9KVGpEdGN4bGZLSWU0eDhUazV2RTRSenM3ZDh5K0FVejFoSmw1bXpL?=
 =?utf-8?B?ay9kdit5SFdjZjhOeDhQNUNHdGc4b2lmd1RUc1VMVFJnOUgvcmVzZW1XNXN6?=
 =?utf-8?B?aWxuLzhLN0VFZ01xNjR6bXdmMTdZWmg2cndhTUMvTTg0YkNTUDMrTzgyazh1?=
 =?utf-8?B?QUcrWGlkMjJCc0JBQmxFVEd1Z2xnUnd3ekJOM216cHI4dGIraC9TOEtwT1Fz?=
 =?utf-8?B?R3pNeDJ6WXlIVDUxUlFuS2ZxdllOY1JwcWVDR09KOGpLWFM5ckhHWjl5ZnNQ?=
 =?utf-8?B?bms1WXpva1hNbU8rdU84L25WNkxGajN6Wm1JTHZEeUV0b29VUUlFRmpQOHI2?=
 =?utf-8?B?VWhZZHpsOVdUMjZlcDU0VEdpMFdpTG1YR3dKZ2czckQvTEx4Q0pSZnFoU3VT?=
 =?utf-8?B?UXR2bmNEM05tNm5GWVJFMUt4WVQzdzhsWm4xZ3hBRFdmMndCVm8xKzRqMHpW?=
 =?utf-8?B?RGV1V2tqak5qb2w1OGRzb20vekxlS2FtNERxTUNNaUdoRmh0SGFCMUlvSnRR?=
 =?utf-8?Q?CDaGhn9OPCVjPMOE8LbkrBDyQpgfJwAbmI9nBO/?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d4da11a-f64d-40b6-c77c-08d9843ce1a0
X-MS-Exchange-CrossTenant-AuthSource: CH2PR10MB4166.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2021 18:05:27.0369
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: uteJ0vJixvPZHe4/E5a2kuhAOQKuxSHHsCQRa+rqpSPeTgTcOQJNgrmKeuzC0tczpjMTxW9XEV+SS+l1kvvCRELE5Ent7tRVIcqX9C74GmU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR10MB4261
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10123 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 malwarescore=0
 suspectscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001
 definitions=main-2109300110
X-Proofpoint-GUID: 3B-x1EhcvY922cuQMzDNbKW9Ym4RHHjI
X-Proofpoint-ORIG-GUID: 3B-x1EhcvY922cuQMzDNbKW9Ym4RHHjI
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 9/23/21 4:31 PM, Kees Cook wrote:
> The /proc/$pid/wchan file has been broken by default on x86_64 for 4
> years now[1]. As this remains a potential leak of either kernel
> addresses (when symbolization fails) or limited observation of kernel
> function progress, just remove the contents for good.
> 
> Unconditionally set the contents to "0" and also mark the wchan
> field in /proc/$pid/stat with 0.

Hi all,

It looks like there's already been pushback on this idea, but I wanted
to add another voice from a frequent user of /proc/$pid/wchan (via PS).
Much of my job involves diagnosing kernel issues and performance issues
on stable kernels, frequently on production systems where I can't do
anything too invasive. wchan is incredibly useful for these situations,
so much so that we store regular snapshots of ps output, and we expand
the size of the WCHAN column to fit more data (e.g. ps -e -o
pid,wchan=WCHAN-WIDE-COLUMN). Disabling wchan would remove a critical
tool for me and my team.

 From my our team's feedback:
1. It's fine if this needs to have CAP_SYS_ADMIN to read for tasks not
    owned by the calling user; and for non-admin, if the symbolization
    fails, to return 0 just like kallsyms does for unprivileged users.
2. We don't care about the stack of an actively running process
    (/proc/$pid/stack is there for that). We only need WCHAN for
    understanding why a task is blocked.
3. Keeping the function / symbol name in the wchan is ideal (so we can
    pinpoint the exact area that a task is blocked at).

> This leaves kernel/sched/fair.c as the only user of get_wchan(). But
> again, since this was broken for 4 years, was this profiling logic
> actually doing anything useful?

This was only broken with CONFIG_UNWINDER_ORC. You may say this is the
default, but Ubuntu's latest kernel (5.11 in Hirsute) still ships with
CONFIG_UNWINDER_FRAME_POINTER, and many other distributions are the
same. Stable distributions have a lag time picking up new code, and even
longer lag picking up new configurations -- even new defaults.
(Especially when frame pointers are so useful for debugging...) So
saying that this was broken for 4 years is at best misleading. Plenty of
users have been happily using recent kernels when this was supposedly
"broken", on valid configurations, without any issues.

It looks like we've backed off of the decision to rip out 
/proc/$pid/wchan, but I just wanted to chime in, since it feels like the 
discussion is happening without much input from users.

Thanks,
Stephen