From: "Zheng, Lv" <lv.zheng@intel.com>
To: "Chen, Yu C" <yu.c.chen@intel.com>, Andy Lutomirski <luto@amacapital.net>
CC: "Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
        "Brown, Len" <len.brown@intel.com>, Andy Lutomirski <luto@kernel.org>,
        Lv Zheng <zetalog@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Linux ACPI <linux-acpi@vger.kernel.org>
Subject: RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support
Thread-Topic: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support
Thread-Index: AQHRLXRmPAa/FFvXe0+crPugnzjO7J7KrTWAgABxKICAAKu9UA==
Date: Tue, 15 Dec 2015 08:52:30 +0000
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB08722@SHSMSX101.ccr.corp.intel.com>
References: <cover.1446790780.git.lv.zheng@intel.com>
 <cover.1449108825.git.lv.zheng@intel.com>
 <af8b1799e7eec686fbb3bf239f6f400adb3b8082.1449108826.git.lv.zheng@intel.com>
 <CALCETrXeoGZhrNr9OmqFB+i7-tbM+d3sO8uCNnMx40JfDsjoEw@mail.gmail.com>
 <36DF59CE26D8EE47B0655C516E9CE64028686D35@shsmsx102.ccr.corp.intel.com>
In-Reply-To: <36DF59CE26D8EE47B0655C516E9CE64028686D35@shsmsx102.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 3346
Lines: 71

Hi,

> From: Chen, Yu C
> Sent: Tuesday, December 15, 2015 2:13 PM
> 
> Hi, Andy
> 
> > From: Andy Lutomirski [mailto:luto@amacapital.net]
> > Sent: Tuesday, December 15, 2015 7:28 AM
> >
> > On Wed, Dec 2, 2015 at 6:43 PM, Lv Zheng <lv.zheng@intel.com> wrote:
> > > From: Chen Yu <yu.c.chen@intel.com>
> > >
> > > This patch implements acpi_os_readable(). The function is used by
> > > ACPICA AML debugger to validate user specified pointers for dumping
> > > the memory as ACPICA descriptor objects.
> > >
> [cut]
> > >
> > > +bool __acpi_memory_readable(void *pointer, size_t length) {
> > > +       unsigned long obj_start, obj_end;
> > > +       unsigned long start_pfn, end_pfn;
> >
> > What does "readable" mean in this context?

[Lv Zheng] 
The function is used by ACPICA "dump" command.
It accepts an arbitrary address, and tries to dump the memory block specified by the address as an acpi_object.
You can try: "help dump" in the interactive mode to confirm.
While acpi_object is actually all created by kmalloc.
So we just check if the specified memory block belongs to the kernel heap.
The readable/writeable is not so meaningful here as the kernel heap should always be both readable and writeable.

We do a lot of checks in this function in order to allow it to:
1. return true if "pointer" belongs to kernel heap when "length" is 0;
2. return false if "pointer" doesn't belong to kernel heap when "length" is 0;
3. return true if "pointer ~ pointer+length-1" belongs to a kernel heap range;
4. return false if "pointer ~ pointer+length-1" doesn't belong to any kernel heap range.

These checks are weak, but can help to avoid panics if users specify wrong pointers for the "dump" command.

> 'readable' means :  the address provided by the user,
> is a dynamically allocated  virtual address -
> because  the  acpi address space are allocated by 'kmalloc',
> acpi debugger must check if this address is a valid 'kmalloc'
> address before accessing it.
> 
> This function does the sanity check that, the vitual address is a:
> 1.   dynamically allocated address (beyond PAGE_OFFSET , but lower
> than high_memory, VMALLOC_START, eg)
> 2.  besides, the physical address must be direct-mapped(so it would not be a
> hole).

[Lv Zheng] 
There is a special case (possibly hackish) on x86_64.
x86_64 kernel maps kernel image twice.
One is called as high map and the other is called as low map.

Since we use __pa() to convert a virtual address,
If the virtual address belongs to the high map range, __pa() which takes care of converting high map addresses actually returns a physical address where there should also be low map mappings ready for it.
Thus the converted PFN from the result of __pa() will be treated as valid.

But this doesn't mean there is a high map for this virtual address.
x86_64 kernel drops several pages from high map in cleanup_highmap().
So accessing a virtual address that belongs to the holes whose page mappings have been dropped in this function could still result in panic due to no mappings.
By enforcing this check, we can avoid such a case.
Actually no acpi_object's virtual address will belong to high map range.

Thanks and best regards
-Lv
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?