From: "Zheng, Lv" <lv.zheng@intel.com> To: "Chen, Yu C" <yu.c.chen@intel.com>, Andy Lutomirski <luto@amacapital.net>, "Moore, Robert" <robert.moore@intel.com> 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 Date: Wed, 16 Dec 2015 00:25:09 +0000 [thread overview] Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB08C24@SHSMSX101.ccr.corp.intel.com> (raw) In-Reply-To: 36DF59CE26D8EE47B0655C516E9CE64028686D35@shsmsx102.ccr.corp.intel.com Hi, Andy and Yu > From: Zheng, Lv > Sent: Tuesday, December 15, 2015 4:52 PM > > 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. [Lv Zheng] This statement might be wrong, Let me Cc Bob to confirm. Hi, Bob Do we have statically allocated acpi_objects? If we have, we need to change this patch to allow high map .data/.bss segments addresses to pass this check. Thanks and best regards -Lv > 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
WARNING: multiple messages have this Message-ID (diff)
From: "Zheng, Lv" <lv.zheng@intel.com> To: "Chen, Yu C" <yu.c.chen@intel.com>, Andy Lutomirski <luto@amacapital.net>, "Moore, Robert" <robert.moore@intel.com> 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 Date: Wed, 16 Dec 2015 00:25:09 +0000 [thread overview] Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB08C24@SHSMSX101.ccr.corp.intel.com> (raw) In-Reply-To: 36DF59CE26D8EE47B0655C516E9CE64028686D35@shsmsx102.ccr.corp.intel.com [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3840 bytes --] Hi, Andy and Yu > From: Zheng, Lv > Sent: Tuesday, December 15, 2015 4:52 PM > > 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. [Lv Zheng] This statement might be wrong, Let me Cc Bob to confirm. Hi, Bob Do we have statically allocated acpi_objects? If we have, we need to change this patch to allow high map .data/.bss segments addresses to pass this check. Thanks and best regards -Lv > 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Ç+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
next prev parent reply other threads:[~2015-12-16 0:25 UTC|newest] Thread overview: 131+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <8c1016ca8a570ba7c7a1c9f0f88d73cd83cea490> 2015-10-19 2:24 ` [PATCH v2 00/14] ACPICA: 20150930 Release Lv Zheng 2015-10-19 2:24 ` Lv Zheng 2015-10-19 2:24 ` [PATCH v2 01/14] ACPICA: Remove unnecessary conditional compilation Lv Zheng 2015-10-19 2:24 ` Lv Zheng 2015-10-19 2:24 ` [PATCH v2 02/14] ACPICA: iASL: Add symbolic operator support for Index() operator Lv Zheng 2015-10-19 2:24 ` Lv Zheng 2015-10-19 2:24 ` [PATCH v2 03/14] ACPICA: Update exception code for "file not found" error Lv Zheng 2015-10-19 2:24 ` Lv Zheng 2015-10-19 2:24 ` [PATCH v2 04/14] ACPICA: Debugger: Update mutexes used for multithreaded debugger Lv Zheng 2015-10-19 2:24 ` Lv Zheng 2015-10-19 2:24 ` [PATCH v2 05/14] ACPICA: Update NFIT table to rename a flags field Lv Zheng 2015-10-19 2:24 ` Lv Zheng 2015-10-19 2:24 ` [PATCH v2 06/14] ACPICA: Improve typechecking, both compile-time and runtime Lv Zheng 2015-10-19 2:24 ` Lv Zheng 2015-10-19 2:25 ` [PATCH v2 07/14] ACPICA: iASL: General cleanup of the file suffix #defines Lv Zheng 2015-10-19 2:25 ` Lv Zheng 2015-10-19 2:25 ` [PATCH v2 08/14] ACPICA: Linuxize: Export debugger files to Linux Lv Zheng 2015-10-19 2:25 ` Lv Zheng 2015-10-19 2:25 ` [PATCH v2 09/14] ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic Lv Zheng 2015-10-19 2:25 ` Lv Zheng 2015-10-19 21:04 ` Rafael J. Wysocki 2015-10-20 2:03 ` Zheng, Lv 2015-10-20 2:03 ` Zheng, Lv 2015-10-20 7:14 ` Zheng, Lv 2015-10-20 7:14 ` Zheng, Lv 2015-10-19 2:25 ` [PATCH v2 10/14] ACPICA: Debugger: Fix "terminate" command by cleaning up subsystem shutdown logic Lv Zheng 2015-10-19 2:25 ` Lv Zheng 2015-10-19 2:25 ` [PATCH v2 11/14] ACPICA: Debugger: Add thread ID support so that single step mode can only apply to the debugger thread Lv Zheng 2015-10-19 2:25 ` Lv Zheng 2015-10-19 2:25 ` [PATCH v2 12/14] ACPI: Enable build of AML interpreter debugger Lv Zheng 2015-10-19 2:25 ` Lv Zheng 2015-10-19 2:26 ` [PATCH v2 13/14] ACPICA: Debugger: Fix dead lock issue ocurred in single stepping mode Lv Zheng 2015-10-19 2:26 ` Lv Zheng 2015-10-19 2:26 ` [PATCH v2 14/14] ACPICA: Update version to 20150930 Lv Zheng 2015-10-19 2:26 ` Lv Zheng 2015-11-06 6:46 ` [RFC PATCH v2 0/5] ACPICA / debugger: Add in-kernel AML debugger support Lv Zheng 2015-11-06 6:46 ` Lv Zheng 2015-11-06 6:46 ` [RFC PATCH v2 1/5] ACPICA: Debugger: Remove unnecessary status check Lv Zheng 2015-11-06 6:46 ` Lv Zheng 2015-11-06 6:47 ` [RFC PATCH v2 2/5] ACPICA: Debugger: Convert some mechanisms to OSPM specific Lv Zheng 2015-11-06 6:47 ` Lv Zheng 2015-11-06 6:47 ` [RFC PATCH v2 3/5] ACPI / debugger: Add IO interface to access debugger functionalities Lv Zheng 2015-11-06 6:47 ` Lv Zheng 2015-11-06 6:47 ` [RFC PATCH v2 4/5] tools/power/acpi: Add userspace AML interface support Lv Zheng 2015-11-06 6:47 ` Lv Zheng 2015-11-06 6:47 ` [RFC PATCH v2 5/5] ACPI / debugger: Add module support for ACPI debugger Lv Zheng 2015-11-06 6:47 ` Lv Zheng 2015-11-10 8:21 ` [PATCH v2 0/7] ACPICA / debugger: Add in-kernel AML debugger support Lv Zheng 2015-11-10 8:21 ` Lv Zheng 2015-11-10 8:21 ` [PATCH v2 1/7] ACPICA: Debugger: Remove unnecessary status check Lv Zheng 2015-11-10 8:21 ` Lv Zheng 2015-11-10 8:21 ` [PATCH v2 2/7] ACPICA: Debugger: Convert some mechanisms to OSPM specific Lv Zheng 2015-11-10 8:21 ` Lv Zheng 2015-11-10 8:21 ` [PATCH v2 3/7] ACPICA: Debugger: Fix runtime stub issues of ACPI_DEBUGGER_EXEC using different stub mechanism Lv Zheng 2015-11-10 8:21 ` Lv Zheng 2015-11-10 8:22 ` [PATCH v2 4/7] ACPI / debugger: Add IO interface to access debugger functionalities Lv Zheng 2015-11-10 8:22 ` Lv Zheng 2015-11-10 8:22 ` [PATCH v2 5/7] ACPI / x86: introduce acpi_os_readable() support Lv Zheng 2015-11-10 8:22 ` Lv Zheng 2015-11-10 9:42 ` Chen, Yu C 2015-11-10 10:46 ` Chen, Yu C 2015-11-10 13:04 ` Andy Shevchenko 2015-11-10 13:56 ` Chen, Yu C 2015-11-10 13:56 ` Chen, Yu C 2015-11-11 5:06 ` Zheng, Lv 2015-11-11 5:27 ` Chen, Yu C 2015-11-17 1:49 ` Zheng, Lv 2015-11-10 8:22 ` [PATCH v2 6/7] tools/power/acpi: Add userspace AML interface support Lv Zheng 2015-11-10 8:22 ` Lv Zheng 2015-11-10 8:22 ` [PATCH v2 7/7] ACPI / debugger: Add module support for ACPI debugger Lv Zheng 2015-11-10 8:22 ` Lv Zheng 2015-11-19 6:08 ` [PATCH v3 0/6] ACPICA / debugger: Add in-kernel AML debugger support Lv Zheng 2015-11-19 6:08 ` Lv Zheng 2015-11-19 6:08 ` [PATCH v3 1/6] ACPICA: Debugger: Remove unnecessary status check Lv Zheng 2015-11-19 6:08 ` Lv Zheng 2015-11-19 6:08 ` [PATCH v3 2/6] ACPICA: Debugger: Convert some mechanisms to OSPM specific Lv Zheng 2015-11-19 6:08 ` Lv Zheng 2015-11-19 6:08 ` [PATCH v3 3/6] ACPICA: Debugger: Fix runtime stub issues of ACPI_DEBUGGER_EXEC using different stub mechanism Lv Zheng 2015-11-19 6:08 ` Lv Zheng 2015-11-19 6:08 ` [PATCH v3 4/6] ACPI / debugger: Add IO interface to access debugger functionalities Lv Zheng 2015-11-19 6:08 ` Lv Zheng 2015-11-19 6:08 ` [PATCH v3 5/6] tools/power/acpi: Add userspace AML interface support Lv Zheng 2015-11-19 6:08 ` Lv Zheng 2015-11-19 6:09 ` [PATCH v3 6/6] ACPI / debugger: Add module support for ACPI debugger Lv Zheng 2015-11-19 6:09 ` Lv Zheng 2015-11-19 6:09 ` [PATCH v3] ACPI / x86: introduce acpi_os_readable() support Lv Zheng 2015-11-19 6:09 ` Lv Zheng 2015-12-03 2:40 ` [PATCH v4 0/7] ACPICA / debugger: Add in-kernel AML debugger support Lv Zheng 2015-12-03 2:40 ` Lv Zheng 2015-12-03 2:42 ` [PATCH v4 1/7] ACPICA: Debugger: Remove unnecessary status check Lv Zheng 2015-12-03 2:42 ` Lv Zheng 2015-12-03 2:42 ` [PATCH v4 2/7] ACPICA: Debugger: Convert some mechanisms to OSPM specific Lv Zheng 2015-12-03 2:42 ` Lv Zheng 2015-12-03 2:42 ` [PATCH v4 3/7] ACPICA: Debugger: Fix runtime stub issues of ACPI_DEBUGGER_EXEC using different stub mechanism Lv Zheng 2015-12-03 2:42 ` Lv Zheng 2015-12-03 2:43 ` [PATCH v4 4/7] ACPI / debugger: Add IO interface to access debugger functionalities Lv Zheng 2015-12-03 2:43 ` Lv Zheng 2015-12-03 22:27 ` Andy Lutomirski 2015-12-03 23:34 ` Rafael J. Wysocki 2015-12-03 2:43 ` [PATCH v4 5/7] tools/power/acpi: Add userspace AML interface support Lv Zheng 2015-12-03 2:43 ` Lv Zheng 2015-12-03 2:43 ` [PATCH v4 6/7] ACPI / debugger: Add module support for ACPI debugger Lv Zheng 2015-12-03 2:43 ` Lv Zheng 2015-12-03 2:43 ` [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support Lv Zheng 2015-12-03 2:43 ` Lv Zheng 2015-12-14 23:28 ` Andy Lutomirski 2015-12-15 6:13 ` Chen, Yu C 2015-12-15 6:13 ` Chen, Yu C 2015-12-15 8:52 ` Zheng, Lv 2015-12-15 8:52 ` Zheng, Lv 2015-12-16 0:25 ` Zheng, Lv [this message] 2015-12-16 0:25 ` Zheng, Lv 2015-12-17 16:59 ` Andy Lutomirski 2015-12-22 1:03 ` Chen, Yu C 2015-12-22 1:03 ` Chen, Yu C 2015-12-22 22:49 ` Andy Lutomirski 2015-12-23 3:25 ` Zheng, Lv 2015-12-23 3:25 ` Zheng, Lv 2015-12-24 1:40 ` Andy Lutomirski 2015-12-24 7:57 ` Chen, Yu C 2015-12-24 7:57 ` Chen, Yu C 2015-12-24 8:01 ` Chen, Yu C 2015-12-24 8:01 ` Chen, Yu C 2015-12-14 23:43 ` Rafael J. Wysocki 2015-12-14 23:44 ` [PATCH v4 0/7] ACPICA / debugger: Add in-kernel AML debugger support Rafael J. Wysocki 2015-12-15 2:55 ` Zheng, Lv 2015-12-15 2:55 ` Zheng, Lv 2015-12-24 6:16 ` [PATCH] ACPI / debugger: Fix an issue a flag is modified without locking Lv Zheng 2015-12-24 6:16 ` Lv Zheng 2015-12-25 3:22 ` [PATCH] ACPI / debugger: Fix a redundant mutex unlock issue in acpi_aml_open() Lv Zheng 2015-12-25 3:22 ` Lv Zheng
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=1AE640813FDE7649BE1B193DEA596E883BB08C24@SHSMSX101.ccr.corp.intel.com \ --to=lv.zheng@intel.com \ --cc=len.brown@intel.com \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=luto@kernel.org \ --cc=rafael.j.wysocki@intel.com \ --cc=robert.moore@intel.com \ --cc=yu.c.chen@intel.com \ --cc=zetalog@gmail.com \ /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: linkBe 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.