linux-kernel - [PATCH 11/27] ACPICA: OSL: Add configurability for memory allocation macros.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Apr 2014 10:04:42 +0800
From:	Lv Zheng <lv.zheng@...el.com>
To:	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Len Brown <len.brown@...el.com>
Cc:	Lv Zheng <lv.zheng@...el.com>, Lv Zheng <zetalog@...il.com>,
	<linux-kernel@...r.kernel.org>, linux-acpi@...r.kernel.org,
	Bob Moore <robert.moore@...el.com>
Subject: [PATCH 11/27] ACPICA: OSL: Add configurability for memory allocation macros.

OSPMs like Linux trend to include all header files but leave empty stub
macros for a feature that is not configured during build.

For macros defined without other symbols referencesd it is safe to leave
them without protections.

By investigation, there are only the following internal/external
symbols referenced by the ACPICA macros:
1. C library symbols, including string, ctype, stdarg APIs.  Since such
   symbols are always accessbile in the kernel source tree, it is safe to
   leave macros referencing them without protected for Linux.
2. ACPICA OSL symbols, such symbols are designed to be used only by ACPICA
   internal APIs.  And there are macros directly referencing mutex and
   memory allocation OSL symbols.  We need to examine the external usages
   of such macros.
   For macros referencing the mutex OSL symbols, fortunately, there is no
   external user directly invoking such macros.
   ========================================================================
   !! IMPORTANT !!
   ========================================================================
   For macros referencing memory allocation OSL symbols -
    1. 'free' - ACPI_FREE
    2. 'alloc' - ACPI_ALLOCATE, ACPI_ALLOCATE_ZEROED, ACPI_ALLOCATE_BUFFER,
                 ACPI_ALLOCATE_LOCAL_BUFFER
   there are external users directly invoking 'alloc' macros.  And the more
   complicated situation is the reversals of such macros are not ACPI_FREE
   but acpi_os_free (or kfree) in Linux.  Though we can define such macros
   into no-op, we in fact cannot define their reversals into no-op.
   This patch adds mechanism to protect ACPICA memory allocation APIs for
   Linux so that acpi_os_free (or kfree) invoked in Linux can have a zero
   address returned by 'alloc' macros to free.  In this
   way, acpi_os_free (or kfree) can be converted into no-op.
   ========================================================================
3. ACPI_OFFSET and other macros that would access structure members, we
   need to check if such structure members are not accessible under a
   specific configuration.  Fortunately, currently Linux doesn't use such
   structure members when CONFIG_ACPI is disabled.

This patch thus only adds mechanism useful for implementing stubs for
ACPICA provided macros - the configurability of memory allocation APIs.

This patch doesn't include code for Linux to use this new mechanism, thus
no functional changes.  Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@...el.com>
Signed-off-by: Bob Moore <robert.moore@...el.com>
---
 include/acpi/actypes.h |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index e763565..19b26bb 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -329,6 +329,15 @@ typedef u32 acpi_physical_address;
  *
  ******************************************************************************/
 
+#ifdef ACPI_NO_MEM_ALLOCATIONS
+
+#define ACPI_ALLOCATE(a)                NULL
+#define ACPI_ALLOCATE_ZEROED(a)         NULL
+#define ACPI_FREE(a)
+#define ACPI_MEM_TRACKING(a)
+
+#else				/* ACPI_NO_MEM_ALLOCATIONS */
+
 #ifdef ACPI_DBG_TRACK_ALLOCATIONS
 /*
  * Memory allocation tracking (used by acpi_exec to detect memory leaks)
@@ -350,6 +359,8 @@ typedef u32 acpi_physical_address;
 
 #endif				/* ACPI_DBG_TRACK_ALLOCATIONS */
 
+#endif				/* ACPI_NO_MEM_ALLOCATIONS */
+
 /******************************************************************************
  *
  * ACPI Specification constants (Do not change unless the specification changes)
@@ -928,9 +939,19 @@ struct acpi_object_list {
  * Miscellaneous common Data Structures used by the interfaces
  */
 #define ACPI_NO_BUFFER              0
+
+#ifdef ACPI_NO_MEM_ALLOCATIONS
+
+#define ACPI_ALLOCATE_BUFFER        (acpi_size) (0)
+#define ACPI_ALLOCATE_LOCAL_BUFFER  (acpi_size) (0)
+
+#else				/* ACPI_NO_MEM_ALLOCATIONS */
+
 #define ACPI_ALLOCATE_BUFFER        (acpi_size) (-1)	/* Let ACPICA allocate buffer */
 #define ACPI_ALLOCATE_LOCAL_BUFFER  (acpi_size) (-2)	/* For internal use only (enables tracking) */
 
+#endif				/* ACPI_NO_MEM_ALLOCATIONS */
+
 struct acpi_buffer {
 	acpi_size length;	/* Length in bytes of the buffer */
 	void *pointer;		/* pointer to buffer */
-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/