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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 58CB1C28CBC for ; Sat, 9 May 2020 05:40:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D8E6D21775 for ; Sat, 9 May 2020 05:40:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BMBuKorf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8E6D21775 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 27231900030; Sat, 9 May 2020 01:40:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2232390001C; Sat, 9 May 2020 01:40:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1134B900030; Sat, 9 May 2020 01:40:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0115.hostedemail.com [216.40.44.115]) by kanga.kvack.org (Postfix) with ESMTP id E9F6690001C for ; Sat, 9 May 2020 01:40:40 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9460A2493 for ; Sat, 9 May 2020 05:40:40 +0000 (UTC) X-FDA: 76796081040.11.joke35_7a3eca1f6cb1a X-HE-Tag: joke35_7a3eca1f6cb1a X-Filterd-Recvd-Size: 6468 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Sat, 9 May 2020 05:40:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589002839; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wLITgYcnji+lI1/U32+qXSFD10JDWBM8uaMukB/H0iE=; b=BMBuKorf8KO7G9tVP1lytZJ3ohSLmi5zruYPf1wElrCDfRNZ6+CeiN7mSdcMG+t7AW/QXy G9Zi022TWqN+i8cZTdN+TJdhQWeVfeeMeH0oEn7LFM2qA3ihqyW3Zv+3ZLC47Yl7EfhHmz qnJKylNisDOWoCyxXqZ9tCacAuLPJ9s= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-429-WISi3ZdEMPG1-4o3sYbaqA-1; Sat, 09 May 2020 01:40:36 -0400 X-MC-Unique: WISi3ZdEMPG1-4o3sYbaqA-1 Received: by mail-wr1-f72.google.com with SMTP id p2so16785wrm.6 for ; Fri, 08 May 2020 22:40:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=mTjszWW/EefMrw7aIGeEPuK1Cqsav+nLkGOW2S21ZN0=; b=DlfUbjmLuesrpeKY39sLMDSoKQwlxZztRAFmEUh2Hlfl4QCpb3zkYWUHvuh9iq0VXu ZbB4T/VcTcipFrK2drtzSRJeB1Du8pfxjbqYLqaWkkQC4pe6dA1haBCObdr1fl8U/yMx /TPYOABDT0jImDeRfGVLtnIXpO0lycMUl/CYvpdj86o5JZJ4+ZKwBZpJ11Eo/LHKqmGS iT1YzPufWuNjece/THiIx0j7KawnLiX86FlP+7sbsuC3FdgPngd9QZjOCq/Ms1HufIgZ kpbxIN6hcz7qxVtdZjKq1HtUV9muHJ74ilSz+kY8vcCphfyDyisJW8DgISwUsa4XOqif PNBw== X-Gm-Message-State: AGi0PuarryrFKq6FeZmunJoNE0TNAXboQCc40x+qTYv53JwPUO2MhTrb V0ps12OLK6GELga2mcb9AaSuFEG0GNs0Yb7BpZYUcTPx6nnsBnvbQCidLVRaZQXjSNzM0Vwn5/A myxMKOQnvjAI= X-Received: by 2002:a5d:52ce:: with SMTP id r14mr7021349wrv.334.1589002835882; Fri, 08 May 2020 22:40:35 -0700 (PDT) X-Google-Smtp-Source: APiQypLh46b+OJHiK+BmOVxHBKBIBg126/s6UEDmzeKxMWF5zY7CcNlENVRlnP1JVfzUUAXHjN/rxA== X-Received: by 2002:a5d:52ce:: with SMTP id r14mr7021307wrv.334.1589002835393; Fri, 08 May 2020 22:40:35 -0700 (PDT) Received: from ?IPv6:2a01:598:b901:53f:9037:7517:2497:29c? ([2a01:598:b901:53f:9037:7517:2497:29c]) by smtp.gmail.com with ESMTPSA id z6sm437028wrq.1.2020.05.08.22.40.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 22:40:34 -0700 (PDT) From: David Hildenbrand Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v4 1/4] device-dax: Don't leak kernel memory to user space after unloading kmem Date: Sat, 9 May 2020 07:40:33 +0200 Message-Id: References: <20200508165306.7cd806f7e451c5c9bc2a40ac@linux-foundation.org> Cc: David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, kexec@lists.infradead.org, Vishal Verma , Dave Jiang , Pavel Tatashin , stable@vger.kernel.org, Dan Williams In-Reply-To: <20200508165306.7cd806f7e451c5c9bc2a40ac@linux-foundation.org> To: Andrew Morton X-Mailer: iPhone Mail (17D50) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > Am 09.05.2020 um 01:53 schrieb Andrew Morton : >=20 > =EF=BB=BFOn Fri, 8 May 2020 10:42:14 +0200 David Hildenbrand wrote: >=20 >> Assume we have kmem configured and loaded: >> [root@localhost ~]# cat /proc/iomem >> ... >> 140000000-33fffffff : Persistent Memory$ >> 140000000-1481fffff : namespace0.0 >> 150000000-33fffffff : dax0.0 >> 150000000-33fffffff : System RAM >>=20 >> Assume we try to unload kmem. This force-unloading will work, even if >> memory cannot get removed from the system. >> [root@localhost ~]# rmmod kmem >> [ 86.380228] removing memory fails, because memory [0x000000015000000= 0-0x0000000157ffffff] is onlined >> ... >> [ 86.431225] kmem dax0.0: DAX region [mem 0x150000000-0x33fffffff] ca= nnot be hotremoved until the next reboot >>=20 >> Now, we can reconfigure the namespace: >> [root@localhost ~]# ndctl create-namespace --force --reconfig=3Dnamespa= ce0.0 --mode=3Ddevdax >> [ 131.409351] nd_pmem namespace0.0: could not reserve region [mem 0x14= 0000000-0x33fffffff]dax >> [ 131.410147] nd_pmem: probe of namespace0.0 failed with error -16name= space0.0 --mode=3Ddevdax >> ... >>=20 >> This fails as expected due to the busy memory resource, and the memory >> cannot be used. However, the dax0.0 device is removed, and along its nam= e. >>=20 >> The name of the memory resource now points at freed memory (name of the >> device). >> [root@localhost ~]# cat /proc/iomem >> ... >> 140000000-33fffffff : Persistent Memory >> 140000000-1481fffff : namespace0.0 >> 150000000-33fffffff : =EF=BF=BD_=EF=BF=BD^7_=EF=BF=BD=EF=BF=BD/_=EF= =BF=BD=EF=BF=BDwR=EF=BF=BD=EF=BF=BDWQ=EF=BF=BD=EF=BF=BD=EF=BF=BD^=EF=BF=BD= =EF=BF=BD=EF=BF=BD ... >> 150000000-33fffffff : System RAM >>=20 >> We have to make sure to duplicate the string. While at it, remove the >> superfluous setting of the name and fixup a stale comment. >>=20 >> Fixes: 9f960da72b25 ("device-dax: "Hotremove" persistent memory that is = used like normal RAM") >> Cc: stable@vger.kernel.org # v5.3 >=20 > hm. >=20 > Is this really -stable material? These are all privileged operations, > I expect? Yes, my thought was rather that an admin could bring the system into such a= state (by mistake?). Let=E2=80=98s see if somebody has a suggestion. I guess if we were really unlucky, we could access invalid memory and trigg= er a BUG (e.g., page at the end of memory and does not contain a 0 byte). >=20 > Assuming "yes", I've queued this separately, staged for 5.7-rcX. I'll > redo patches 2-4 as a three-patch series for 5.8-rc1. Make sense, let=E2=80=98s wait for review feedback, thanks!