Re: [kernel-hardening] [PATCH] doc: self-protection: provide initial details

[Greg KH]

On Mon, May 16, 2016 at 07:27:28PM -0700, Kees Cook wrote:
> This document attempts to codify the intent around kernel self-protection
> along with discussion of both existing and desired technologies, with
> attention given to the rationale behind them, and the expectations of
> their usage.
> 
> Signed-off-by: Kees Cook 
> ---
>  Documentation/security/self-protection.txt | 261 
> +
>  1 file changed, 261 insertions(+)
>  create mode 100644 Documentation/security/self-protection.txt

Nice job:

Reviewed-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] doc: self-protection: provide initial details

[Kees Cook]

This document attempts to codify the intent around kernel self-protection
along with discussion of both existing and desired technologies, with
attention given to the rationale behind them, and the expectations of
their usage.

Signed-off-by: Kees Cook 
---
 Documentation/security/self-protection.txt | 261 +
 1 file changed, 261 insertions(+)
 create mode 100644 Documentation/security/self-protection.txt

diff --git a/Documentation/security/self-protection.txt 
b/Documentation/security/self-protection.txt
new file mode 100644
index ..33ad7183a074
--- /dev/null
+++ b/Documentation/security/self-protection.txt
@@ -0,0 +1,261 @@
+# Kernel Self-Protection
+
+Kernel self-protection is the design and implementation of systems and
+structures within the Linux kernel to protect against security flaws in
+the kernel itself. This covers a wide range of issues, including removing
+entire classes of bugs, blocking security flaw exploitation methods,
+and actively detecting attack attempts. Not all topics are explored in
+this document, but it should serve as a reasonable starting point and
+answer any frequently asked questions. (Patches welcome, of course!)
+
+In the worst-case scenario, we assume an unprivileged local attacker
+has arbitrary read and write access to the kernel's memory. In many
+cases, bugs being exploited will not provide this level of access,
+but with systems in place that defend against the worst case we'll
+cover the more limited cases as well. A higher bar, and one that should
+still be kept in mind, is protecting the kernel against a _privileged_
+local attacker, since the root user has access to a vastly increased
+attack surface. (Especially when they have the ability to load arbitrary
+kernel modules.)
+
+The goals for successful self-protection systems would be to that they
+are effective, on by default, require no opt-in by developers, have no
+performance impact, do not impede kernel debugging, and have tests. It
+is uncommon that all these goals can be met, but it is worth explicitly
+mentioning them, since these aspects need to be explored, dealt with,
+and/or accepted.
+
+
+## Attack Surface Reduction
+
+The most fundamental defense against security exploits is to reduce the
+areas of the kernel that can be used to redirect execution. This ranges
+from limiting the exposed APIs available to userspace, making in-kernel
+APIs hard to use incorrectly, minimizing the areas of writable kernel
+memory, etc.
+
+### Strict kernel memory permissions
+
+When all of kernel memory is writable, it becomes trivial for attacks
+to redirect execution flow. To reduce the availability of these targets
+the kernel needs to protect its memory with a tight set of permissions.
+
+ Executable code and read-only data must not be writable
+
+Any areas of the kernel with executable memory must not be writable.
+While this obviously includes the kernel text itself, we must consider
+all additional places too: kernel modules, JIT memory, etc. (There are
+temporary exceptions to this rule to support things like instruction
+alternatives, breakpoints, kprobes, etc. If these must exist in a
+kernel, they are implemented in a way where the memory is temporarily
+made writable during the update, and then returned to the original
+permissions.)
+
+In support of this are (the poorly named) CONFIG_DEBUG_RODATA and
+CONFIG_DEBUG_SET_MODULE_RONX, which seek to make sure that code is not
+writable, data is not executable, and read-only data is neither writable
+nor executable.
+
+ Function pointers and sensitive variables must not be writable
+
+Vast areas of kernel memory contain function pointers that are looked
+up by the kernel and used to continue execution (e.g. descriptor/vector
+tables, file/network/etc operation structures, etc). The number of these
+variables must be reduced to an absolute minimum.
+
+Many such variables can be made read-only by setting them "const"
+so that they live in the .rodata section instead of the .data section
+of the kernel, gaining the protection of the kernel's strict memory
+permissions as described above.
+
+For variables that are initialized once at __init time, these can
+be marked with the (new and under development) __ro_after_init
+attribute.
+
+What remains are variables that are updated rarely (e.g. GDT). These
+will need another infrastructure (similar to the temporary exceptions
+made to kernel code mentioned above) that allow them to spend the rest
+of their lifetime read-only. (For example, when being updated, only the
+CPU thread performing the update would be given uninterruptable write
+access to the memory.)
+
+ Segregation of kernel memory from userspace memory
+
+The kernel must never execute userspace memory. The kernel must also never
+access userspace memory without explicit expectation to do so. These
+rules can be enforced either by support of hardware-based restrictions
+(x86's SMEP/SMAP, ARM's PXN/PAN) or v

Re: [PATCH v5 0/1] ARM64: ACPI: Update documentation for latest specification version

[Alexey Klimov]

On Mon, May 2, 2016 at 09:19 PM, Al Stone wrote:
> On 04/25/2016 03:21 PM, Al Stone wrote:
> > The ACPI 6.1 specification was recently released at the end of January
> > 2016, but the arm64 kernel documentation for the use of ACPI was written
> > for the 5.1 version of the spec.  There were significant additions to the
> > spec that had not yet been mentioned -- for example, the 6.0 mechanisms
> > added to make it easier to define processors and low power idle states,
> > as well as the 6.1 addition allowing regular interrupts (not just from
> > GPIO) be used to signal ACPI general purpose events.
> >
> > This patch reflects going back through and examining the specs in detail
> > and updating content appropriately.  Whilst there, a few odds and ends of
> > typos were caught as well.  This brings the documentation up to date with
> > ACPI 6.1 for arm64.
> >
> > Changes for v5:
> >-- Miscellaneous typos and corrections (Lorenzo Pieralisi)
> >-- Add linux-acpi@ ML to the distribution list (Alexey Klimov)
> >-- Corrections to CPPC information (Alexey Klimov)
> >-- ACK from Lorenzo Pieralisi
> >-- Updated bibliographic info (Al Stone)
> >
> > Changes for v4:
> >-- Clarify that IORT can sometimes be optional (Jon Masters).
> >-- Remove "Use as needed" descriptions of ACPI objects; they provide
> >   no substantive information and doing so simplifies maintenance of
> >   this document over time.  These have been replaced with a simpler
> >   notice that states that unless otherwise noted, do what the ACPI
> >   specification says is needed.
> >-- Corrected the _OSI object usage recommendation; it described kernel
> >   behavior that does not exist (Al Stone).
> >
> > Changes for v3:
> >-- Clarify use of _LPI/_RDI (Vikas Sajjan)
> >-- Whitespace cleanup as pointed out by checkpatch
> >
> > Changes for v2:
> >-- Clean up white space (Harb Abdulhahmid)
> >-- Clarification on _CCA usage (Harb Abdulhamid)
> >-- IORT moved to required from recommended (Hanjun Guo)
> >-- Clarify IORT description (Hanjun Guo)
> >
> >
> > Al Stone (1):
> >   ARM64: ACPI: Update documentation for latest specification version
> >
> >  Documentation/arm64/acpi_object_usage.txt | 343 
> > --
> >  Documentation/arm64/arm-acpi.txt  |  40 ++--
> >  2 files changed, 213 insertions(+), 170 deletions(-)
> >
> 
> Ping?  If there are no further comments, can this be pulled in through
> either the documentation or arm64 tree?
> 
> Thanks.

Hi Al,
sorry for delay.

CPPC and PCC corrections look fine. Thanks.


This comment is not to block your patch (maybe some to-do):
I greped sources and your patch and I don't see description of _PSD object.
This P-state dependancy object is optional but it's presense and correct data
are extremely useful for CPPC and can potentially descrease number of 
performance
changing requests.

ACPI spec in section about CPPC tells that it may use _PSD (page 503 if I 
remember
correctly) to specify domain belongings of CPUs.

You may consider to add description of _PSD object later.

Best regards,
Alexey.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/4] x86, boot: KASLR memory randomization

[Thomas Garnier]

Any feedback on the patch? Ingo? Kees?

Kees mentioned he will take care of the build warning on the KASLR
refactor (the function is not used right now).

Thanks,
Thomas

On Thu, May 12, 2016 at 12:28 PM, Thomas Garnier  wrote:
> This is PATCH v5 for KASLR memory implementation for x86_64.
>
> Recent changes:
> Add performance information on commit.
> Add details on PUD alignment.
> Add information on testing against the KASLR bypass exploit.
> Rebase on next-20160511 and merge recent KASLR changes.
> Integrate feedback from Kees.
>
> ***Background:
> The current implementation of KASLR randomizes only the base address of
> the kernel and its modules. Research was published showing that static
> memory can be overwitten to elevate privileges bypassing KASLR.
>
> In more details:
>
>The physical memory mapping holds most allocations from boot and heap
>allocators. Knowning the base address and physical memory size, an
>attacker can deduce the PDE virtual address for the vDSO memory page.
>This attack was demonstrated at CanSecWest 2016, in the "Getting
>Physical Extreme Abuse of Intel Based Paged Systems"
>https://goo.gl/ANpWdV (see second part of the presentation). The
>exploits used against Linux worked successfuly against 4.6+ but fail
>with KASLR memory enabled (https://goo.gl/iTtXMJ). Similar research
>was done at Google leading to this patch proposal. Variants exists to
>overwrite /proc or /sys objects ACLs leading to elevation of privileges.
>These variants were tested against 4.6+.
>
> This set of patches randomizes base address and padding of three
> major memory sections (physical memory mapping, vmalloc & vmemmap).
> It mitigates exploits relying on predictable kernel addresses. This
> feature can be enabled with the CONFIG_RANDOMIZE_MEMORY option.
>
> Padding for the memory hotplug support is managed by
> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING. The default value is 10
> terabytes.
>
> The patches were tested on qemu & physical machines. Xen compatibility was
> also verified. Multiple reboots were used to verify entropy for each
> memory section.
>
> ***Problems that needed solving:
>  - The three target memory sections are never at the same place between
>boots.
>  - The physical memory mapping can use a virtual address not aligned on
>the PGD page table.
>  - Have good entropy early at boot before get_random_bytes is available.
>  - Add optional padding for memory hotplug compatibility.
>
> ***Parts:
>  - The first part prepares for the KASLR memory randomization by
>refactoring entropy functions used by the current implementation and
>support PUD level virtual addresses for physical mapping.
>(Patches 01-02)
>  - The second part implements the KASLR memory randomization for all
>sections mentioned.
>(Patch 03)
>  - The third part adds support for memory hotplug by adding an option to
>define the padding used between the physical memory mapping section
>and the others.
>(Patch 04)
>
> Performance data:
>
> Kernbench shows almost no difference (-+ less than 1%):
>
> Before:
>
> Average Optimal load -j 12 Run (std deviation):
> Elapsed Time 102.63 (1.2695)
> User Time 1034.89 (1.18115)
> System Time 87.056 (0.456416)
> Percent CPU 1092.9 (13.892)
> Context Switches 199805 (3455.33)
> Sleeps 97907.8 (900.636)
>
> After:
>
> Average Optimal load -j 12 Run (std deviation):
> Elapsed Time 102.489 (1.10636)
> User Time 1034.86 (1.36053)
> System Time 87.764 (0.49345)
> Percent CPU 1095 (12.7715)
> Context Switches 199036 (4298.1)
> Sleeps 97681.6 (1031.11)
>
> Hackbench shows 0% difference on average (hackbench 90
> repeated 10 times):
>
> attemp,before,after
> 1,0.076,0.069
> 2,0.072,0.069
> 3,0.066,0.066
> 4,0.066,0.068
> 5,0.066,0.067
> 6,0.066,0.069
> 7,0.067,0.066
> 8,0.063,0.067
> 9,0.067,0.065
> 10,0.068,0.071
> average,0.0677,0.0677
>
> Thanks!
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

[Catalin Marinas]

On Sat, May 14, 2016 at 06:03:52PM +0300, Yury Norov wrote:
> +SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
> +   unsigned long, prot, unsigned long, flags, unsigned long, fd,
> +   unsigned long, pgoff)

To avoid the types confusion we could add __SC_WRAP to mmap2 in unistd.h
and use COMPAT_SYSCALL_DEFINE6 here (together with compat_ptr_t etc.).

> +{
> +   if (pgoff & (~PAGE_MASK >> 12))
> +   return -EINVAL;
> +
> +   return sys_mmap_pgoff((compat_uptr_t) addr, (compat_size_t) len,
> +(int) prot, (int) flags, (int) fd,
> +pgoff >> (PAGE_SHIFT-12));

Then we wouldn't need the explicit casting here.

> +}
> +
> +COMPAT_SYSCALL_DEFINE4(pread64, unsigned int, fd, compat_uptr_t __user *, 
> ubuf,
> +compat_size_t, count, off_t, offset)
> +{
> + return sys_pread64(fd, (char *) ubuf, count, offset);
> +}
> +
> +COMPAT_SYSCALL_DEFINE4(pwrite64, unsigned int, fd, compat_uptr_t __user *, 
> ubuf,
> +compat_size_t, count, off_t, offset)
> +{
> + return sys_pwrite64(fd, (char *) ubuf, count, offset);

Nitpick: no space between cast type and variable name: (char *)ubuf, ...

We can also make these functions static as they are not used outside
this file.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] Documentation: dtb: xgene: Add hwmon dts binding documentation

[Hoan Tran]

This patch adds the APM X-Gene hwmon device tree node documentation.

Signed-off-by: Hoan Tran 
---
 .../devicetree/bindings/hwmon/apm-xgene-hwmon.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt

diff --git a/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt 
b/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt
new file mode 100644
index 000..49a482e
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt
@@ -0,0 +1,14 @@
+APM X-Gene hwmon driver
+
+Hwmon driver accesses sensors over the "SLIMpro" mailbox.
+
+Required properties :
+ - compatible : should be "apm,xgene-slimpro-hwmon"
+ - mboxes : use the label reference for the mailbox as the first parameter.
+   The second parameter is the channel number.
+
+Example :
+   hwmonslimpro {
+   compatible = "apm,xgene-slimpro-hwmon";
+   mboxes = <&mailbox 7>;
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] arm64: dts: apm: Add X-Gene SoC hwmon to device tree

[Hoan Tran]

This patch adds DT node to enable hwmon driver for APM X-Gene SoC.

Signed-off-by: Hoan Tran 
---
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 5 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi 
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index a055a5d..672c0ce 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -472,6 +472,11 @@
mboxes = <&mailbox 0>;
};
 
+   hwmonslimpro {
+   compatible = "apm,xgene-slimpro-hwmon";
+   mboxes = <&mailbox 7>;
+   };
+
serial0: serial@1060 {
device_type = "serial";
compatible = "ns16550";
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index ae4a173..7a59159 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -716,6 +716,11 @@
mboxes = <&mailbox 0>;
};
 
+   hwmonslimpro {
+   compatible = "apm,xgene-slimpro-hwmon";
+   mboxes = <&mailbox 7>;
+   };
+
serial0: serial@1c02 {
status = "disabled";
device_type = "serial";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] Add support for X-Gene hwmon driver

[Hoan Tran]

This patch set adds hardware temperature and power reading support ​for
APM X-Gene SoC's using the mailbox communication interface.
For device tree, it is the standard DT mailbox.
For ACPI, it is the PCC mailbox.

For ACPI, tested with this patch[1] which supports PCC subspace 2
[1] https://lkml.org/lkml/2016/5/6/482
 - [PATCH v2] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

Hoan Tran (3):
  Documentation: dtb: xgene: Add hwmon dts binding documentation
  hwmon: xgene: Adds hwmon driver
  arm64: dts: apm: Add X-Gene SoC hwmon to device tree

 .../devicetree/bindings/hwmon/apm-xgene-hwmon.txt  |  14 +
 Documentation/hwmon/xgene-hwmon|  32 +
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi |   5 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   5 +
 drivers/hwmon/Kconfig  |   7 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/xgene-hwmon.c| 801 +
 7 files changed, 865 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/apm-xgene-hwmon.txt
 create mode 100644 Documentation/hwmon/xgene-hwmon
 create mode 100644 drivers/hwmon/xgene-hwmon.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] hwmon: xgene: Adds hwmon driver

[Hoan Tran]

This patch adds hardware temperature and power reading support for
APM X-Gene SoC's using the mailbox communication interface.

Signed-off-by: Hoan Tran 
---
 Documentation/hwmon/xgene-hwmon |  32 ++
 drivers/hwmon/Kconfig   |   7 +
 drivers/hwmon/Makefile  |   1 +
 drivers/hwmon/xgene-hwmon.c | 801 
 4 files changed, 841 insertions(+)
 create mode 100644 Documentation/hwmon/xgene-hwmon
 create mode 100644 drivers/hwmon/xgene-hwmon.c

diff --git a/Documentation/hwmon/xgene-hwmon b/Documentation/hwmon/xgene-hwmon
new file mode 100644
index 000..040a7f2
--- /dev/null
+++ b/Documentation/hwmon/xgene-hwmon
@@ -0,0 +1,32 @@
+Kernel driver xgene-hwmon
+
+
+Supported chips:
+ * APM X-Gene SoC
+
+Description
+---
+
+This driver adds hardware temperature and power reading support for
+APM X-Gene SoC's using the mailbox communication interface.
+For device tree, it is the standard DT mailbox.
+For ACPI, it is the PCC mailbox.
+
+The following sensors are supported
+
+  * Temperature
+- SoC on-die temperature in milli-degree
+- Alarm when high/over temperature occurs
+  * Power
+- CPU power in uW
+- IO power in uW
+- CPU and IO power in uW
+
+sysfs-Interface
+---
+
+temp1_input - SoC on-die temperature (milli-degree C)
+temp1_critical_alarm - An 1 would indicates on-die temperature exceeded 
threshold
+power1_input - CPU power in (uW)
+power2_input - IO power in (uW)
+power3_input - CPU and IO power in (uW)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5c2d13a..91c3056 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1776,6 +1776,13 @@ config SENSORS_ULTRA45
  This driver provides support for the Ultra45 workstation environmental
  sensors.
 
+config SENSORS_XGENE
+   tristate "APM X-Gene SoC hardware monitoring driver"
+   depends on XGENE_SLIMPRO_MBOX || PCC
+   help
+ If you say yes here you get support for the temperature
+ and power sensors for APM X-Gene SoC.
+
 if ACPI
 
 comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 58cc3ac..668d0f1 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
 obj-$(CONFIG_SENSORS_W83L786NG)+= w83l786ng.o
 obj-$(CONFIG_SENSORS_WM831X)   += wm831x-hwmon.o
 obj-$(CONFIG_SENSORS_WM8350)   += wm8350-hwmon.o
+obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
 
 obj-$(CONFIG_PMBUS)+= pmbus/
 
diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
new file mode 100644
index 000..bc4ad29
--- /dev/null
+++ b/drivers/hwmon/xgene-hwmon.c
@@ -0,0 +1,801 @@
+/*
+ * APM X-Gene SoC Hardware Monitoring Driver
+ *
+ * Copyright (c) 2016, Applied Micro Circuits Corporation
+ * Author: Loc Ho 
+ * Hoan Tran 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ *
+ * This driver provides the following features:
+ *  - Retrieve CPU's total power (uW)
+ *  - Retrieve IO's total power (uW)
+ *  - Retrieve SoC total power (uW)
+ *  - Retrieve SoC temperature (milli-degree C) and alarm
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* SLIMpro message defines */
+#define SLIMPRO_MSG_TYPE_DBG_ID0
+#define SLIMPRO_MSG_TYPE_ERR_ID7
+#define SLIMPRO_MSG_TYPE_PWRMGMT_ID9
+
+#define SLIMPRO_MSG_TYPE(v)(((v) & 0xF000) >> 28)
+#define SLIMPRO_MSG_TYPE_SET(v)(((v) << 28) & 0xF000)
+#define SLIMPRO_MSG_SUBTYPE(v) (((v) & 0x0F00) >> 24)
+#define SLIMPRO_MSG_SUBTYPE_SET(v) (((v) << 24) & 0x0F00)
+
+#define SLIMPRO_DBG_SUBTYPE_SENSOR_READ4
+#define SLIMPRO_SENSOR_READ_MSG0x04FFE902
+#define SLIMPRO_SENSOR_READ_ENCODE_ADDR(a) \
+   ((a) & 0x000F)
+#define PMD_PWR_MW_REG 0x26
+#define SOC_PWR_REG0x21
+#define SOC_TEMP_REG   0x10
+
+#define SLIMPRO_PWRMGMT_SUBTYPE_TPC1
+#define SLIMPRO_TPC_ALARM  2
+#define SLIMPRO_TPC_GET_ALARM  3
+#define SLIMPRO_TPC_CMD(v) (((v) & 0x00FF) >> 16)
+#define SLIMPRO_TPC_CMD_SET(v) (((v) << 16) & 0x00FF)
+#define SLI