All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	George Kennedy <george.kennedy@oracle.com>,
	Robert Moore <robert.moore@intel.com>,
	Erik Kaneda <erik.kaneda@intel.com>,
	Rafael Wysocki <rafael.j.wysocki@intel.com>,
	Len Brown <lenb@kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	"open list:ACPI COMPONENT ARCHITECTURE (ACPICA)"
	<devel@acpica.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Dhaval Giani <dhaval.giani@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Oscar Salvador <osalvador@suse.de>,
	Wei Yang <richard.weiyang@linux.alibaba.com>,
	Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
	Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH 1/1] ACPI: fix acpi table use after free
Date: Wed, 10 Mar 2021 19:39:19 +0100	[thread overview]
Message-ID: <CAJZ5v0gC+60n0-UkMw8h5JPBc6grQtD1ambSOCAHV2HLm886yQ@mail.gmail.com> (raw)
In-Reply-To: <1ae44491-4404-6873-4ee6-6cf58c1ae6fb@redhat.com>

On Fri, Mar 5, 2021 at 2:40 PM David Hildenbrand <david@redhat.com> wrote:
>
> >> The ibft table, for example, is mapped in via acpi_map() and kmap(). The
> >> page for the ibft table is not reserved, so it can end up on the freelist.
> >
> > You appear to be saying that it is not sufficient to kmap() a page in
> > order to use it safely.  It is also necessary to reserve it upfront,
> > for example with the help of memblock_reserve().  Is that correct?  If
> > so, is there an alternative way to reserve a page frame?
>
> If the memory is indicated by the BIOS/firmware as valid memory
> (!reserved) but contains actual tables that have to remain untouched
> what happens is:
>
> 1) Memblock thinks the memory should be given to the buddy, because it
>     is valid memory and was not reserved by anyone (i.e., the bios, early
>     allocations).
>
> 2) Memblock will expose the pages to the buddy, adding them to the free
>     page list.
>
> 3) Anybody can allocate them, e.g., via alloc_pages().
>
> The root issue is that pages that should not get exposed to the buddy as
> free pages get exposed to the buddy as free pages. We have to teach
> memblock that these pages are not actually to be used, but instead, area
> reserved.
>
> >
> >>>
> >>>> Use memblock_reserve() to reserve all the ACPI table pages.
> >>> How is this going to help?
> >> If the ibft table page is not reserved, it will end up on the freelist
> >> and potentially be allocated before ibft_init() is called.
> >>
> >> I believe this is the call that causes the ibft table page (in this case
> >> pfn=0xbe453) to end up on the freelist:
> >>
> >> memmap_init_range: size=bd49b, nid=0, zone=1, start_pfn=1000,
> >> zone_end_pfn=100000
> >
> > David, is commit 7fef431be9c9 related to this and if so, then how?
> >
>
> Memory gets allocated and used in a different order, which seems to have
> exposed (yet another) latent BUG.

Well, you can call it that, or you can say that things worked under
certain assumptions regarding the memory allocation order which are
not met any more.

> The same could be reproduced via zone shuffling with a little luck.

But nobody does that in practice.

This would be relatively straightforward to address if ACPICA was not
involved in it, but unfortunately that's not the case.

Changing this part of ACPICA is risky, because such changes may affect
other OSes using it, so that requires some serious consideration.
Alternatively, the previous memory allocation order in Linux could be
restored.

WARNING: multiple messages have this Message-ID (diff)
From: Rafael J. Wysocki <rafael at kernel.org>
To: devel@acpica.org
Subject: [Devel] Re: [PATCH 1/1] ACPI: fix acpi table use after free
Date: Wed, 10 Mar 2021 19:39:19 +0100	[thread overview]
Message-ID: <CAJZ5v0gC+60n0-UkMw8h5JPBc6grQtD1ambSOCAHV2HLm886yQ@mail.gmail.com> (raw)
In-Reply-To: 1ae44491-4404-6873-4ee6-6cf58c1ae6fb@redhat.com

[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]

On Fri, Mar 5, 2021 at 2:40 PM David Hildenbrand <david(a)redhat.com> wrote:
>
> >> The ibft table, for example, is mapped in via acpi_map() and kmap(). The
> >> page for the ibft table is not reserved, so it can end up on the freelist.
> >
> > You appear to be saying that it is not sufficient to kmap() a page in
> > order to use it safely.  It is also necessary to reserve it upfront,
> > for example with the help of memblock_reserve().  Is that correct?  If
> > so, is there an alternative way to reserve a page frame?
>
> If the memory is indicated by the BIOS/firmware as valid memory
> (!reserved) but contains actual tables that have to remain untouched
> what happens is:
>
> 1) Memblock thinks the memory should be given to the buddy, because it
>     is valid memory and was not reserved by anyone (i.e., the bios, early
>     allocations).
>
> 2) Memblock will expose the pages to the buddy, adding them to the free
>     page list.
>
> 3) Anybody can allocate them, e.g., via alloc_pages().
>
> The root issue is that pages that should not get exposed to the buddy as
> free pages get exposed to the buddy as free pages. We have to teach
> memblock that these pages are not actually to be used, but instead, area
> reserved.
>
> >
> >>>
> >>>> Use memblock_reserve() to reserve all the ACPI table pages.
> >>> How is this going to help?
> >> If the ibft table page is not reserved, it will end up on the freelist
> >> and potentially be allocated before ibft_init() is called.
> >>
> >> I believe this is the call that causes the ibft table page (in this case
> >> pfn=0xbe453) to end up on the freelist:
> >>
> >> memmap_init_range: size=bd49b, nid=0, zone=1, start_pfn=1000,
> >> zone_end_pfn=100000
> >
> > David, is commit 7fef431be9c9 related to this and if so, then how?
> >
>
> Memory gets allocated and used in a different order, which seems to have
> exposed (yet another) latent BUG.

Well, you can call it that, or you can say that things worked under
certain assumptions regarding the memory allocation order which are
not met any more.

> The same could be reproduced via zone shuffling with a little luck.

But nobody does that in practice.

This would be relatively straightforward to address if ACPICA was not
involved in it, but unfortunately that's not the case.

Changing this part of ACPICA is risky, because such changes may affect
other OSes using it, so that requires some serious consideration.
Alternatively, the previous memory allocation order in Linux could be
restored.

  parent reply	other threads:[~2021-03-10 18:40 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03 20:09 [PATCH 1/1] ACPI: fix acpi table use after free George Kennedy
2021-03-04 12:14 ` Rafael J. Wysocki
2021-03-04 12:14   ` [Devel] " Rafael J. Wysocki
2021-03-04 23:14   ` George Kennedy
2021-03-05 13:30     ` Rafael J. Wysocki
2021-03-05 13:30       ` [Devel] " Rafael J. Wysocki
2021-03-05 13:40       ` David Hildenbrand
2021-03-05 15:24         ` George Kennedy
2021-03-10 18:39         ` Rafael J. Wysocki [this message]
2021-03-10 18:39           ` [Devel] " Rafael J. Wysocki
2021-03-10 18:54           ` Rafael J. Wysocki
2021-03-10 18:54             ` [Devel] " Rafael J. Wysocki
2021-03-10 19:10             ` David Hildenbrand
2021-03-10 19:38               ` Mike Rapoport
2021-03-10 19:47                 ` David Hildenbrand
2021-03-11 15:36                   ` Rafael J. Wysocki
2021-03-11 15:36                     ` [Devel] " Rafael J. Wysocki
2021-03-14 18:59                     ` Mike Rapoport
2021-03-15 16:19                       ` Rafael J. Wysocki
2021-03-15 16:19                         ` [Devel] " Rafael J. Wysocki
2021-03-15 18:05                         ` Rafael J. Wysocki
2021-03-15 18:05                           ` [Devel] " Rafael J. Wysocki
2021-03-17 20:14                         ` Rafael J. Wysocki
2021-03-17 20:14                           ` [Devel] " Rafael J. Wysocki
2021-03-17 22:28                           ` George Kennedy
2021-03-18 15:42                             ` Rafael J. Wysocki
2021-03-18 15:42                               ` [Devel] " Rafael J. Wysocki
2021-03-18  7:25                           ` Mike Rapoport
2021-03-18 10:50                             ` Rafael J. Wysocki
2021-03-18 10:50                               ` [Devel] " Rafael J. Wysocki
2021-03-18 15:22                               ` Rafael J. Wysocki
2021-03-18 15:22                                 ` [Devel] " Rafael J. Wysocki
2021-03-20  8:25                                 ` Mike Rapoport
2021-03-22 16:57                                   ` Rafael J. Wysocki
2021-03-22 16:57                                     ` [Devel] " Rafael J. Wysocki
2021-03-23 19:26                                   ` [PATCH] ACPI: tables: x86: Reserve memory occupied by ACPI tables Rafael J. Wysocki
2021-03-24  8:24                                     ` Mike Rapoport
2021-03-24 13:27                                       ` Rafael J. Wysocki
2021-03-24 13:49                                         ` George Kennedy
2021-03-24 15:42                                         ` George Kennedy
2021-03-24 15:44                                           ` Rafael J. Wysocki
2021-03-07  7:46       ` [PATCH 1/1] ACPI: fix acpi table use after free Mike Rapoport
2021-03-09 17:54         ` Mike Rapoport
2021-03-09 18:29           ` Rafael J. Wysocki
2021-03-09 18:29             ` [Devel] " Rafael J. Wysocki
2021-03-09 20:16             ` Mike Rapoport

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=CAJZ5v0gC+60n0-UkMw8h5JPBc6grQtD1ambSOCAHV2HLm886yQ@mail.gmail.com \
    --to=rafael@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=dan.carpenter@oracle.com \
    --cc=david@redhat.com \
    --cc=devel@acpica.org \
    --cc=dhaval.giani@oracle.com \
    --cc=erik.kaneda@intel.com \
    --cc=george.kennedy@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --cc=pankaj.gupta.linux@gmail.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=richard.weiyang@linux.alibaba.com \
    --cc=robert.moore@intel.com \
    --cc=rppt@linux.ibm.com \
    --cc=vbabka@suse.cz \
    /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.