Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp10935094rwp; Fri, 21 Jul 2023 07:05:44 -0700 (PDT) X-Google-Smtp-Source: APBJJlHGAKP5rASmNvOWrq8hUHmeoFn/lo/IQOHpycXtqKvrPJr2DCK/RlsY/MaZa0w8OQg17Ntv X-Received: by 2002:a17:90a:e514:b0:267:a6a8:26c0 with SMTP id t20-20020a17090ae51400b00267a6a826c0mr1414025pjy.4.1689948343748; Fri, 21 Jul 2023 07:05:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689948343; cv=none; d=google.com; s=arc-20160816; b=iHEsBDWtGsI8ZleGWb609gA6UVFwMc5/eiO5LZY4NRkd/1+lMvqK+9/dRETwwU0t03 B9iPJKGcvw5ILQo84EYKG8j2IPQcLC1SD0vlzg/Vagq1aied9g2wfuIblEN4wT1WkcP6 EApovMZ/pOB5W6h8HTTuT7H65jk6JgIoYBDZjsWakWueFnKhNV92Es4+0T8atRB1hGud i7NPNuKX8R+ssZxqG6LJ2qgIKBJEWQwPZdMEiq/R785L9FKuFbLxnoYDEbUlsyFTrpMo v8OT6qvFdcL8ebAnTlJE0Agg4oliwOHJ2bHvV2LcyhBnbPJGt2uv1SKJOGsZNH2OVhsD 3k/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=+59IsCifznfcjfYMwQ8rMA4IccTRHGWrePtCutftbmo=; fh=tRdODEgv3/MlgTZ8hNsdYkBre6LsIsPTfJIwh4FPHJY=; b=lZhlckZVREMiv6L3F3ePRS6tx36h18DnWHLYLb3jOYdmwU/oaMaNuiqMurueJHP9oa pxSJ8mHJ1DGotz80M+kPwsoRw8DKqfBNnnnufBIfveBkIwuYMCeQjymgp4Nx97UwO9de gh4lxKitCmL5oJuiK98qAvcVj+IBQG6P5m/Kn1qXcBVMWpRLdS00zarNbUHDA+ciFJvn /jn0Xnjz7r8guCi6LETsg/cvAh8M4QPTGiEa/fGA8oBPzHup8fQ3YSvjspfKV7HenHAz CJaG/8phrky+ac2tMdVSmUqQ95k0UUi+IOHQmyIdwmmSYEvm3gNe6nWPe5YgNflPMOfN ks1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bLbUYlsY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cv21-20020a17090afd1500b002640bed79cesi5588943pjb.122.2023.07.21.07.05.11; Fri, 21 Jul 2023 07:05:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bLbUYlsY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229936AbjGUNtg (ORCPT + 99 others); Fri, 21 Jul 2023 09:49:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229536AbjGUNte (ORCPT ); Fri, 21 Jul 2023 09:49:34 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C117C273C for ; Fri, 21 Jul 2023 06:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689947328; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+59IsCifznfcjfYMwQ8rMA4IccTRHGWrePtCutftbmo=; b=bLbUYlsY+AYSL6VYXzrOPuIaLzX+b9qBtPKznadw9YrS8/zx+EaRGhPj5aWAIUTEgMv3zC 7na/Xhi0rfDcyvZadppId7fuGZfJrsa0fEg9dEO3UQm5B763BYUvjwKT2GS6vfbuzsZs+s 7to7YyocaWe2evawTHATWIVUpq1Hr6k= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-512-_7G0T2gjOm2_EVha-4a6RQ-1; Fri, 21 Jul 2023 09:48:42 -0400 X-MC-Unique: _7G0T2gjOm2_EVha-4a6RQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 092A93815EEE; Fri, 21 Jul 2023 13:48:42 +0000 (UTC) Received: from localhost (ovpn-12-18.pek2.redhat.com [10.72.12.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1FE16492B03; Fri, 21 Jul 2023 13:48:40 +0000 (UTC) Date: Fri, 21 Jul 2023 21:48:37 +0800 From: Baoquan He To: Jiri Olsa Cc: Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Uladzislau Rezki , Matthew Wilcox , David Hildenbrand , Liu Shixin , Jens Axboe , Alexander Viro Subject: Re: [PATCH v8 1/4] fs/proc/kcore: avoid bounce buffer for ktext data Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jiri, On 05/31/23 at 01:58pm, Jiri Olsa wrote: > On Thu, Mar 23, 2023 at 10:15:16AM +0000, Lorenzo Stoakes wrote: > > Commit df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext data") > > introduced the use of a bounce buffer to retrieve kernel text data for > > /proc/kcore in order to avoid failures arising from hardened user copies > > enabled by CONFIG_HARDENED_USERCOPY in check_kernel_text_object(). > > > > We can avoid doing this if instead of copy_to_user() we use _copy_to_user() > > which bypasses the hardening check. This is more efficient than using a > > bounce buffer and simplifies the code. > > > > We do so as part an overall effort to eliminate bounce buffer usage in the > > function with an eye to converting it an iterator read. > > > > Signed-off-by: Lorenzo Stoakes > > Reviewed-by: David Hildenbrand > > hi, > sorry for late feedback, but looks like this one breaks reading > /proc/kcore with objdump for me: > > # cat /proc/kallsyms | grep ksys_read > ffffffff8150ebc0 T ksys_read > # objdump -d --start-address=0xffffffff8150ebc0 --stop-address=0xffffffff8150ebd0 /proc/kcore > > /proc/kcore: file format elf64-x86-64 > > objdump: Reading section load1 failed because: Bad address > > reverting this makes it work again I met this too when I executed below command to trigger a kcore reading. I wanted to do a simple testing during system running and got this. makedumpfile --mem-usage /proc/kcore Later I tried your above objdump testing, it corrupted system too. Is there any conclusion about this issue you reported? I could miss things in the discussion or patch posting to fix this. Thanks Baoquan > > > > --- > > fs/proc/kcore.c | 17 +++++------------ > > 1 file changed, 5 insertions(+), 12 deletions(-) > > > > diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c > > index 71157ee35c1a..556f310d6aa4 100644 > > --- a/fs/proc/kcore.c > > +++ b/fs/proc/kcore.c > > @@ -541,19 +541,12 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos) > > case KCORE_VMEMMAP: > > case KCORE_TEXT: > > /* > > - * Using bounce buffer to bypass the > > - * hardened user copy kernel text checks. > > + * We use _copy_to_user() to bypass usermode hardening > > + * which would otherwise prevent this operation. > > */ > > - if (copy_from_kernel_nofault(buf, (void *)start, tsz)) { > > - if (clear_user(buffer, tsz)) { > > - ret = -EFAULT; > > - goto out; > > - } > > - } else { > > - if (copy_to_user(buffer, buf, tsz)) { > > - ret = -EFAULT; > > - goto out; > > - } > > + if (_copy_to_user(buffer, (char *)start, tsz)) { > > + ret = -EFAULT; > > + goto out; > > } > > break; > > default: > > -- > > 2.39.2 > > >