[PATCH] acpi: Better describe ACPI_DEBUGGER

[PATCH] acpi: Better describe ACPI_DEBUGGER

[Peter Zijlstra]

Hi,

For a brief moment I was tricked into thinking that:

  In-kernel debugger (EXPERIMENTAL) (ACPI_DEBUGGER) [N/y/?] (NEW)

might be something useful. Better describe the feature to reduce
such confusion.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 drivers/acpi/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 25dbb76c02cc..5eef4cb4f70e 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -58,10 +58,10 @@ config ACPI_CCA_REQUIRED
 	bool
 
 config ACPI_DEBUGGER
-	bool "In-kernel debugger (EXPERIMENTAL)"
+	bool "AML debugger interface (EXPERIMENTAL)"
 	select ACPI_DEBUG
 	help
-	  Enable in-kernel debugging facilities: statistics, internal
+	  Enable in-kernel debugging of AML facilities: statistics, internal
 	  object dump, single step control method execution.
 	  This is still under development, currently enabling this only
 	  results in the compilation of the ACPICA debugger files.

Re: [PATCH] acpi: Better describe ACPI_DEBUGGER

[Peter Zijlstra]

On Mon, Nov 30, 2015 at 11:43:26PM +0100, Rafael J. Wysocki wrote:
> On Monday, November 30, 2015 10:32:15 PM Peter Zijlstra wrote:
> > Hi,
> > 
> > For a brief moment I was tricked into thinking that:
> > 
> >   In-kernel debugger (EXPERIMENTAL) (ACPI_DEBUGGER) [N/y/?] (NEW)
> > 
> > might be something useful. Better describe the feature to reduce
> > such confusion.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> 
> Applied, thanks!
> 
> I should have caught that, sorry for the sloppiness.

n/p, for a brief moment I thought about things like a GDB stub running
in SMM -- which would be entirely awesome if it had dedicated IO through
a BMC or simple serial.

Then I thought about all the kvm-gdb-stub fail I've encountered over the
years and figured this would never work, seeing how BIOSes are never
updated/fixed.

Re: [PATCH] acpi: Better describe ACPI_DEBUGGER

[Rafael J. Wysocki]

On Monday, November 30, 2015 10:32:15 PM Peter Zijlstra wrote:
> Hi,
> 
> For a brief moment I was tricked into thinking that:
> 
>   In-kernel debugger (EXPERIMENTAL) (ACPI_DEBUGGER) [N/y/?] (NEW)
> 
> might be something useful. Better describe the feature to reduce
> such confusion.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Applied, thanks!

I should have caught that, sorry for the sloppiness.

Thanks,
Rafael

Re: [PATCH] acpi: Better describe ACPI_DEBUGGER

[Blibbet]

On 11/30/2015 02:39 PM, Peter Zijlstra wrote:
> On Mon, Nov 30, 2015 at 11:43:26PM +0100, Rafael J. Wysocki wrote:
>> On Monday, November 30, 2015 10:32:15 PM Peter Zijlstra wrote:
[...]
> n/p, for a brief moment I thought about things like a GDB stub running
> in SMM -- which would be entirely awesome if it had dedicated IO through
> a BMC or simple serial.
>
> Then I thought about all the kvm-gdb-stub fail I've encountered over the
> years and figured this would never work, seeing how BIOSes are never
> updated/fixed.

FYI, at Usenix WOOT'15, Intel talked about using a GDB stub to test SMM,
along with S2E, KLEE, OpenOCD, and Minnow. I *think* Intel is going to
be open-sourcing the resulting test project next quarter. Unclear if
this will impact ACPI.

https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk

"Symbolic Execution for BIOS Security: We are building a tool that uses
symbolic execution to search for BIOS security vulnerabilities including
dangerous memory references (call outs) by SMM interrupt handlers in
UEFI-compliant implementations of BIOS. Our tool currently applies only
to interrupt handlers for SMM variables. Given a snapshot of SMRAM, the
base address of SMRAM, and the address of the variable interrupt handler
in SMRAM, the tool uses S2E to run the KLEE symbolic execution engine to
search for concrete examples of a call to the interrupt handler that
causes the handler to read memory outside of SMRAM. This is a work in
progress. We discuss our approach, our current status, our plans for the
tool, and the obstacles we face."

Thanks,
Lee
RSS: http://firmwaresecurity.com/feed