From: David Hildenbrand <david@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-nvdimm@lists.01.org, kexec@lists.infradead.org,
Pavel Tatashin <pasha.tatashin@soleen.com>,
stable@vger.kernel.org
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 [thread overview]
Message-ID: <B72EB609-44DC-4133-820C-9BEA95CA012D@redhat.com> (raw)
In-Reply-To: <20200508165306.7cd806f7e451c5c9bc2a40ac@linux-foundation.org>
> Am 09.05.2020 um 01:53 schrieb Andrew Morton <akpm@linux-foundation.org>:
>
> On Fri, 8 May 2020 10:42:14 +0200 David Hildenbrand <david@redhat.com> wrote:
>
>> 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
>>
>> 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 [0x0000000150000000-0x0000000157ffffff] is onlined
>> ...
>> [ 86.431225] kmem dax0.0: DAX region [mem 0x150000000-0x33fffffff] cannot be hotremoved until the next reboot
>>
>> Now, we can reconfigure the namespace:
>> [root@localhost ~]# ndctl create-namespace --force --reconfig=namespace0.0 --mode=devdax
>> [ 131.409351] nd_pmem namespace0.0: could not reserve region [mem 0x140000000-0x33fffffff]dax
>> [ 131.410147] nd_pmem: probe of namespace0.0 failed with error -16namespace0.0 --mode=devdax
>> ...
>>
>> 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 name.
>>
>> 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 : �_�^7_��/_��wR��WQ���^��� ...
>> 150000000-33fffffff : System RAM
>>
>> We have to make sure to duplicate the string. While at it, remove the
>> superfluous setting of the name and fixup a stale comment.
>>
>> Fixes: 9f960da72b25 ("device-dax: "Hotremove" persistent memory that is used like normal RAM")
>> Cc: stable@vger.kernel.org # v5.3
>
> hm.
>
> 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‘s see if somebody has a suggestion.
I guess if we were really unlucky, we could access invalid memory and trigger a BUG (e.g., page at the end of memory and does not contain a 0 byte).
>
> 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‘s wait for review feedback, thanks!
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-nvdimm@lists.01.org, kexec@lists.infradead.org,
Vishal Verma <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
stable@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>
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 [thread overview]
Message-ID: <B72EB609-44DC-4133-820C-9BEA95CA012D@redhat.com> (raw)
In-Reply-To: <20200508165306.7cd806f7e451c5c9bc2a40ac@linux-foundation.org>
> Am 09.05.2020 um 01:53 schrieb Andrew Morton <akpm@linux-foundation.org>:
>
> On Fri, 8 May 2020 10:42:14 +0200 David Hildenbrand <david@redhat.com> wrote:
>
>> 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
>>
>> 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 [0x0000000150000000-0x0000000157ffffff] is onlined
>> ...
>> [ 86.431225] kmem dax0.0: DAX region [mem 0x150000000-0x33fffffff] cannot be hotremoved until the next reboot
>>
>> Now, we can reconfigure the namespace:
>> [root@localhost ~]# ndctl create-namespace --force --reconfig=namespace0.0 --mode=devdax
>> [ 131.409351] nd_pmem namespace0.0: could not reserve region [mem 0x140000000-0x33fffffff]dax
>> [ 131.410147] nd_pmem: probe of namespace0.0 failed with error -16namespace0.0 --mode=devdax
>> ...
>>
>> 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 name.
>>
>> 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 : �_�^7_��/_��wR��WQ���^��� ...
>> 150000000-33fffffff : System RAM
>>
>> We have to make sure to duplicate the string. While at it, remove the
>> superfluous setting of the name and fixup a stale comment.
>>
>> Fixes: 9f960da72b25 ("device-dax: "Hotremove" persistent memory that is used like normal RAM")
>> Cc: stable@vger.kernel.org # v5.3
>
> hm.
>
> 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‘s see if somebody has a suggestion.
I guess if we were really unlucky, we could access invalid memory and trigger a BUG (e.g., page at the end of memory and does not contain a 0 byte).
>
> 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‘s wait for review feedback, thanks!
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Jiang <dave.jiang@intel.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
linux-nvdimm@lists.01.org,
Vishal Verma <vishal.l.verma@intel.com>,
David Hildenbrand <david@redhat.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, linux-mm@kvack.org,
Dan Williams <dan.j.williams@intel.com>
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 [thread overview]
Message-ID: <B72EB609-44DC-4133-820C-9BEA95CA012D@redhat.com> (raw)
In-Reply-To: <20200508165306.7cd806f7e451c5c9bc2a40ac@linux-foundation.org>
> Am 09.05.2020 um 01:53 schrieb Andrew Morton <akpm@linux-foundation.org>:
>
> On Fri, 8 May 2020 10:42:14 +0200 David Hildenbrand <david@redhat.com> wrote:
>
>> 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
>>
>> 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 [0x0000000150000000-0x0000000157ffffff] is onlined
>> ...
>> [ 86.431225] kmem dax0.0: DAX region [mem 0x150000000-0x33fffffff] cannot be hotremoved until the next reboot
>>
>> Now, we can reconfigure the namespace:
>> [root@localhost ~]# ndctl create-namespace --force --reconfig=namespace0.0 --mode=devdax
>> [ 131.409351] nd_pmem namespace0.0: could not reserve region [mem 0x140000000-0x33fffffff]dax
>> [ 131.410147] nd_pmem: probe of namespace0.0 failed with error -16namespace0.0 --mode=devdax
>> ...
>>
>> 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 name.
>>
>> 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 : �_�^7_��/_��wR��WQ���^��� ...
>> 150000000-33fffffff : System RAM
>>
>> We have to make sure to duplicate the string. While at it, remove the
>> superfluous setting of the name and fixup a stale comment.
>>
>> Fixes: 9f960da72b25 ("device-dax: "Hotremove" persistent memory that is used like normal RAM")
>> Cc: stable@vger.kernel.org # v5.3
>
> hm.
>
> 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‘s see if somebody has a suggestion.
I guess if we were really unlucky, we could access invalid memory and trigger a BUG (e.g., page at the end of memory and does not contain a 0 byte).
>
> 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‘s wait for review feedback, thanks!
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2020-05-09 5:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-08 8:42 [PATCH v4 0/4] mm/memory_hotplug: Interface to add driver-managed system ram David Hildenbrand
2020-05-08 8:42 ` David Hildenbrand
2020-05-08 8:42 ` David Hildenbrand
2020-05-08 8:42 ` [PATCH v4 1/4] device-dax: Don't leak kernel memory to user space after unloading kmem David Hildenbrand
2020-05-08 8:42 ` David Hildenbrand
2020-05-08 8:42 ` David Hildenbrand
2020-05-08 23:53 ` Andrew Morton
2020-05-08 23:53 ` Andrew Morton
2020-05-08 23:53 ` Andrew Morton
2020-05-09 5:40 ` David Hildenbrand [this message]
2020-05-09 5:40 ` David Hildenbrand
2020-05-09 5:40 ` David Hildenbrand
2020-05-08 8:42 ` [PATCH v4 2/4] mm/memory_hotplug: Introduce add_memory_driver_managed() David Hildenbrand
2020-05-08 8:42 ` David Hildenbrand
2020-05-08 8:42 ` David Hildenbrand
2020-05-08 8:42 ` [PATCH v4 3/4] kexec_file: Don't place kexec images on IORESOURCE_MEM_DRIVER_MANAGED David Hildenbrand
2020-05-08 8:42 ` David Hildenbrand
2020-05-08 8:42 ` David Hildenbrand
2020-05-08 8:42 ` [PATCH v4 4/4] device-dax: Add memory via add_memory_driver_managed() David Hildenbrand
2020-05-08 8:42 ` David Hildenbrand
2020-05-08 8:42 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B72EB609-44DC-4133-820C-9BEA95CA012D@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=pasha.tatashin@soleen.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.