Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2776615pxb; Tue, 9 Mar 2021 10:31:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJyXMc518HJ1R6FjYIjfmbAXK4efa0i0xBF30LfjaR3jnw4L4oyRV0OGYAZCrSKJmP4SNYU3 X-Received: by 2002:a05:6402:1d33:: with SMTP id dh19mr5659998edb.362.1615314712604; Tue, 09 Mar 2021 10:31:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615314712; cv=none; d=google.com; s=arc-20160816; b=BxKjTBfv2dNkifHxsBM00XNvI9euLjEW85R3iEQQ8steI2PLBH7Bg/ykNGbKjsd1K/ 8RSTt07hdgEGN5sY51GnLhqeIt9jfJ8KiPBWWEfmRb0dlyW3ZC3M6CqqGh2E+rqyUKfp R8iBxo8UicwurH8szQOUktvwchCeaJf9MnObGdAnS925bbSKz7kwoaHNO0LcgxRYAfLo +4/Twgo2BxvFkrikVjWkmn17AydF/rETowTjQbew4HTNa3qlkbuY/Y31OMcsA3xOjPyD v04lnLsEryz4BxBz2zo9nA4+E2/++6/T94U/EQ2lBf2qbihwUi6R0Xz4NA5auAkShQY4 ea1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=cc44XgMrXYcGJmv2uY6Gj2YJymaXa/QmpTtTLJqdQFI=; b=M4U9ktXHwKpxgUiYs4hNPt52sYgm6FqU+5VNX7nI1n1TTwEi4v9oHWBDE87F4lJD2P xq15/5y0dDTOZNeDY8Ksxy1D3V/vLYLY/X5z59v4T9MYDuczeXacNwMhYofIS1AChGYZ oLCVL5dfpOd4dYgondrO86pzV7TvBY05Y7sqxFiL2olPFGx/5mke6o5BblTwnC8jqLul cUenggVsP7z3UJnin/zi4tBGyoieaaNJQsUuOUjhUeCP8E89Y2BB2CR7WYgGycnjTKBH LCdG9mutdE0oCwV2kCOB5UyDDEZj7TuCX+pNIbeB5sq6VCxTeZ0mXfuEzEmTMhNf1O7m QTAg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cx5si9726116edb.555.2021.03.09.10.31.29; Tue, 09 Mar 2021 10:31:52 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229904AbhCISa2 (ORCPT + 99 others); Tue, 9 Mar 2021 13:30:28 -0500 Received: from mail-ot1-f50.google.com ([209.85.210.50]:39296 "EHLO mail-ot1-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230288AbhCISaD (ORCPT ); Tue, 9 Mar 2021 13:30:03 -0500 Received: by mail-ot1-f50.google.com with SMTP id h22so13772650otr.6; Tue, 09 Mar 2021 10:30:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cc44XgMrXYcGJmv2uY6Gj2YJymaXa/QmpTtTLJqdQFI=; b=USW/msloywO14osyG+ECNiIuO9ZgSvBLcJtajMmhV7DtjHVb+zzr83DAxllQfSEjic CjvQkrXnTjukrS6tdqJb6RNOcPpGEC4MrITTPnKWVD9P9MHm5Gx36xDQ6dOqwbVibmfW JdJ86L4VKlfedA6AvT7Iq5K227JgPGw04lb8pYx/szg4V382Kt04vcfTMiML3JSK9dsY 38SUO++Bt/7Pz/PNx6IbiLCkN/jJk5edRSxWPp6Kg2SIzHs7DVQWARgvrUvZguEq32Fj ab8S26E8njSWGNCMOzIGjxHd14JLfZjhO/XeMz1AxHDSRbLrRBtQU+RJ5eAknmdSvj+i NmXw== X-Gm-Message-State: AOAM5307IPWlzi1lSJ85LDEN4tBL7wFwyYeOkaaFye/jax5ncwkSxO6E EEmYTBMtRROIGTwNvUp5QNBP2SrxHo3rmgKXF5E= X-Received: by 2002:a9d:3422:: with SMTP id v31mr20594235otb.260.1615314602894; Tue, 09 Mar 2021 10:30:02 -0800 (PST) MIME-Version: 1.0 References: <1614802160-29362-1-git-send-email-george.kennedy@oracle.com> <9c3bc1b2-bb8d-194d-6faf-e4d7d346dc9b@oracle.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 9 Mar 2021 19:29:51 +0100 Message-ID: Subject: Re: [PATCH 1/1] ACPI: fix acpi table use after free To: Mike Rapoport Cc: "Rafael J. Wysocki" , George Kennedy , David Hildenbrand , Robert Moore , Erik Kaneda , Rafael Wysocki , Len Brown , ACPI Devel Maling List , "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" , Linux Kernel Mailing List , Konrad Rzeszutek Wilk , Dan Carpenter , Dhaval Giani , Andrew Morton , Vlastimil Babka , Oscar Salvador , Wei Yang , Pankaj Gupta , Michal Hocko Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 9, 2021 at 6:54 PM Mike Rapoport wrote: > > On Sun, Mar 07, 2021 at 09:46:22AM +0200, Mike Rapoport wrote: > > Hello Rafael, > > > > On Fri, Mar 05, 2021 at 02:30:07PM +0100, Rafael J. Wysocki wrote: > > > On Fri, Mar 5, 2021 at 12:14 AM George Kennedy 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? > > > > Like David said in the other reply, if a BIOS does not mark the memory that > > contains an ACPI table as used (e.g. reserved or ACPI data), we need to > > make sure the kernel knows that such memory is in use and an early call to > > memblock_reserve() is exactly what we need here. > > George had this issue with iBFT, but in general this could be any table > > that a buggy BIOS forgot to mark as ACPI data. > > BTW, I wonder is there a fundamental reason to use ioremap() to access ACPI > tables at all? > In the end, they reside in RAM and, apparently, they live at the same DIMM > as neighboring "normal memory" so why cannot we just map them normally as > read-only not executable? This may be NVS memory (depending on the configuration of the system) which isn't "normal" RAM AFAICS.