docs/designs/bmc-service-failure-debug-and-recovery.md

# BMC Service Failure Debug and Recovery

Author:
Andrew Jeffery <andrew@aj.id.au> @arj

Primary Assignee:
Andrew Jeffery <andrew@aj.id.au> @arj

Created:
6th May 2021

## Problem Description

The capability to debug critical failures of the BMC firmware is essential to
meet the reliability and serviceability claims made for some platforms.

A class of failure exists under which we can attempt debug data collection
despite being unable to communicate with the BMC via standard protocols.

This proposal argues for and proposes a software-driven debug data capture
and recovery of a failed BMC.

## Background and References

By necessity, BMCs are not self-contained systems. BMCs exist to service the
needs of both the host system by providing in-band platform services such as
thermal and power management as well as system operators by providing
out-of-band system management interfaces such as error reporting, platform
telemetry and firmware management.

As such, failures of BMC subsystems may impact external consumers.

The BMC firmware stack is not trivial, in the sense that common implementations
are usually a domain-specific Linux distributions with complex or highly
coupled relationships to platform subsystems.

Complexity and coupling drive concern around the risk of critical failures in
the BMC firmware. The BMC firmware design should provide for resilience and
recovery in the face of well-defined error conditions, but the need to mitigate
ill-defined error conditions or entering unintended software states remains.

The ability for a system to recover in the face of an error condition depends
on its ability to detect the failure. Thus, error conditions can be assigned to
various classes based on the ability to externally observe the error:

1. Continued operation: The services detects the error and performs the actions
   required to return to its operating state

2. Graceful exit: The service detects an error it cannot recover from, but
   gracefully cleans up its resources before exiting with an appropriate exit
   status

3. Crash: The service detects it is an unintended software state and exits
   immediately, failing to gracefully clean up its resources before exiting

4. Unresponsive: The service fails to detect it cannot make progress and
   continues to run but is unresponsive


As the state transformations to enter the ill-defined or unintended software
state are unanticipated, the actions required to gracefully return to an
expected state are also not well defined. The general approaches to recover a
system or service to a known state in the face of entering an unknown state
are:

1. Restart the affected service
2. Restart the affected set of services
3. Restart all services

In the face of continued operation due to internal recovery a service restart
is unnecessary, while in the case of a unresponsive service the need to restart
cannot be detected by service state alone. Implementation of resiliency by way
of service restarts via a service manager is only possible in the face of a
graceful exit or application crash. Handling of services that have entered an
unresponsive state can only begin upon receiving external input.

Like error conditions, services exposed by the BMC can be divided into several
external interface classes:

1. Providers of platform data
2. Providers of platform data transports

Examples of the first are applications that expose various platform sensors or
provide data about the firmware itself. Failure of the first class of
applications usually yields a system that can continue to operate in a reduced
capacity.

Examples of the second are the operating system itself and applications that
implement IPMI, HTTPS (e.g. for Redfish), MCTP and PLDM. This second class also
covers implementation-specific data transports such as D-Bus, which requires a
broker service. Failure of a platform data transport may result in one or all
external interfaces becoming unresponsive and be viewed as a critical failure
of the BMC.

Like error conditions and services, the BMC's external interfaces can be
divided into several classes:

1. Out-of-band interfaces: Remote, operator-driven platform management
2. In-band interfaces: Local, host-firmware-driven platform management

Failures of platform data transports generally leave out-of-band interfaces
unresponsive to the point that the BMC cannot be recovered except via external
means, usually by issuing a (disruptive) AC power cycle. On the other hand, if
the host can detect the BMC is unresponsive on the in-band interface(s), an
appropriate platform design can enable the host to reset the BMC without
disrupting its own operation.

### Analysis of eBMC Error State Management and Mitigation Mechanisms

Assessing OpenBMC userspace with respect to the error classes outlined above,
the system manages and mitigates error conditions as follows:

| Condition           | Mechanism                                           |
|---------------------|-----------------------------------------------------|
| Continued operation | Application-specific error handling                 |
| Graceful exit       | Application-specific error handling                 |
| Crash               | Signal, unhandled exceptions, `assert()`, `abort()` |
| Unresponsive        | None                                                |

These mechanisms inform systemd (the service manager) of an event, which it
handles according to the restart policy encoded in the unit file for the
service.

Assessing the OpenBMC operating system with respect to the error classes, it
manages and mitigates error conditions as follows:

| Condition           | Mechanism                              |
|---------------------|----------------------------------------|
| Continued operation | ramoops, ftrace, `printk()`            |
| Graceful exit       | System reboot                          |
| Crash               | kdump or ramoops                       |
| Unresponsive        | `hardlockup_panic`, `softlockup_panic` |

Crash conditions in the Linux kernel trigger panics, which are handled by kdump
(though may be handled by ramoops until kdump support is integrated). Kernel
lockup conditions can be configured to trigger panics, which in-turn trigger
either ramoops or kdump.

### Synthesis

In the context of the information above, handling of application lock-up error
conditions is not provided. For applications in the platform-data-provider
class of external interfaces, the system will continue to operate with reduced
functionality. For applications in the platform-data-transport-provider class,
this represents a critical failure of the firmware that must have accompanying
debug data.

## Requirements

### Recovery Mechanisms

The ability for external consumers to control the recovery behaviour of BMC
services is usually coarse, the nuanced handling is left to the BMC
implementation. Where available the options for external consumer tend to be,
in ascending order of severity:

| Severity | BMC Recovery Mechanism  | Used for                                                              |
|----------|-------------------------|-----------------------------------------------------------------------|
| 1        | Graceful reboot request | Normal circumstances or recovery from platform data provider failures |
| 2        | Forceful reboot request | Recovery from unresponsive platform data transport providers          |
| 3        | External hardware reset | Unresponsive operating system                                         |

Of course it's not possible to issue these requests over interfaces that are
unresponsive. A robust platform design should be capable of issuing all three
restart requests over separate interfaces to minimise the impact of any one
interface becoming unresponsive. Further, the more severe the reset type, the
fewer dependencies should be in its execution path.

Given the out-of-band path is often limited to just the network, it's not
feasible for the BMC to provide any of the above in the event of some kind of
network or relevant data transport failure. The considerations here are
therefore limited to recovery of unresponsive in-band interfaces.

The need to escalate above mechanism 1 should come with data that captures why
it was necessary, i.e. dumps for services that failed in the path for 1.
However, by escalating straight to 3, the BMC will necessarily miss out on
capturing a debug dump because there is no opportunity for software to
intervene in the reset. Therefore, mechanism 2 should exist in the system
design and its implementation should capture any appropriate data needed to
debug the need to reboot and the inability to execute on approach 1.

The need to escalate to 3 would indicate that the BMC's own mechanisms for
detecting a kernel lockup have failed. Had they not failed, we would have
ramoops or kdump data to analyse. As data cannot be captured with an escalation
to method 3 the need to invoke it will require its own specialised debug
experience. Given this and the kernel's own lockup detection and data
collection mechanism, support for 2 can be implemented in BMC userspace.

Mechanism 1 is typically initiated by the usual in-band interfaces, either IPMI
or PLDM. In order to avoid these in the implementation of mechanism 2, the host
needs an interface to the BMC that is dedicated to the role of BMC recovery,
with minimal dependencies on the BMC side for initiating the dump collection
and reboot. At its core, all that is needed is the ability to trigger a BMC
IRQ, which could be as simple as monitoring a GPIO.

### Behavioural Requirements for Recovery Mechanism 2

The system behaviour requirement for the mechanism is:

1. The BMC executes collection of debug data and then reboots once it observes
   a recovery message from the host

It's desirable that:

1. The host has some indication that the recovery process has been activated
2. The host has some indication that a BMC reset has taken place

It's necessary that:

1. The host make use of a timeout to escalate to recovery mechanism 3 as it's
   possible the BMC will be unresponsive to recovery mechanism 2

### Analysis of BMC Recovery Mechanisms for Power10 Platforms

The implementation of recovery mechanism 1 is already accounted for in the
in-band protocols between the host and the BMC and so is considered resolved
for the purpose of the discussion.

To address recovery mechanism 3, the Power10 platform designs wire up a GPIO
driven by the host to the BMC's EXTRST pin. If the host firmware detects that
the BMC has become unresponsive to its escalating recovery requests, it can
drive the hardware to forcefully reset the BMC.

However, host-side GPIOs are in short supply, and we do not have a dedicated
pin to implement recovery mechanism 2 in the platform designs.

### Analysis of Implementation Methods on Power10 Platforms

The implementation of recovery mechanism 2 is limited to using existing
interfaces between the host and the BMC. These largely consist of:

1. FSI
2. LPC
3. PCIe

FSI is inappropriate because the host is the peripheral in its relationship
with the BMC. If the BMC has become unresponsive, it is possible it's in a
state where it would not accept FSI traffic (which it needs to drive in the
first place) and we would need an mechanism architected into FSI for the BMC to
recognise it is in a bad state. PCIe and LPC are preferable by comparison as
the BMC is the peripheral in this relationship, with the host driving cycles
into it over either interface. Comparatively, PCIe is more complex than LPC, so
an LPC-based approach is preferred.

The host already makes use of several LPC peripherals exposed from the BMC:

1. Mapped LPC FW cycles
2. iBT for IPMI
3. The VUARTs for system and debug consoles
4. A KCS device for a vendor-defined MCTP LPC binding

The host could take advantage of any of the following LPC peripherals for
implementing recovery mechanism 2:

1. The SuperIO-based iLPC2AHB bridge
2. The LPC mailbox
3. An otherwise unused KCS device

In ASPEED BMC SoCs prior to the AST2600 the LPC mailbox required configuration
via the SuperIO device, which exposes the unrestricted iLPC2AHB backdoor into
the BMC's physical address space. The iLPC2AHB capability could not be
mitigated without disabling SuperIO support entirely, and so the ability to use
the mailbox went with it. This security issue is resolved in the AST2600
design, so the mailbox could be used in the Power10 platforms, but we have
lower-complexity alternatives for generating an IRQ on the BMC. We could use
the iLPC2AHB from the host to drive one of the watchdogs in the BMC to trigger
a reset, but this exposes a stability risk due to the unrestricted power of the
interface, let alone the security implications, and like the mailbox is more
complex than the alternatives.

This draws us towards the use of a KCS device, which is best aligned with the
simple need of generating an IRQ on the BMC. AST2600 has at least 4 KCS devices
of which one is already in use for IBM's vendor-defined MCTP LPC binding
leaving at least 3 from which to choose.

## Proposed Design

The proposed design is for a simple daemon started at BMC boot to invoke the
desired crash dump handler according to the system policy upon receiving the
external signal. The implementation should have no IPC dependencies or
interactions with `init`, as the reason for invoking the recovery mechanism is
unknown and any of these interfaces might be unresponsive.

A trivial implementation of the daemon is

```sh
dd if=$path bs=1 count=1
echo c > /proc/sysrq-trigger
```

For systems with kdump enabled, this will result in a kernel crash dump
collection and the BMC being rebooted.

A more elegant implementation might be to invoke `kexec` directly, but this
requires the support is already available on the platform.

Other activities in userspace might be feasible if it can be assumed that
whatever failure has occurred will not prevent debug data collection, but no
statement about this can be made in general.

### A Idealised KCS-based Protocol for Power10 Platforms

The proposed implementation provides for both the required and desired
behaviours outlined in the requirements section above.

The host and BMC protocol operates as follows, starting with the BMC
application invoked during the boot process:

1. Set the `Ready` bit in STR

2. Wait for an `IBF` interrupt

3. Read `IDR`. The hardware clears IBF as a result

4. If the read value is 0x44 (`D` for "Debug") then execute the debug dump
   collection process and reboot. Otherwise,

5. Go to step 2.

On the host:

1. If the `Ready` bit in STR is clear, escalate to recovery mechanism 3.
   Otherwise,

2. If the `IBF` bit in STR is set, escalate to recovery mechanism 3. Otherwise,

3. Start an escalation timer

4. Write 0x44 (`D` for "Debug") to the Input Data Register (IDR). The hardware
   sets IBF as a result

5. If `IBF` clears before expiry, restart the escalation timer

6. If an STR read generates an LPC SYNC No Response abort, or `Ready` clears
   before expiry, restart the escalation timer

7. If `Ready` becomes set before expiry, disarm the escalation timer. Recovery
   is complete. Otherwise,

8. Escalate to recovery mechanism 3 if the escalation timer expires at any
   point

A SerIRQ is unnecessary for correct operation of the protocol. The BMC-side
implementation is not required to emit one and the host implementation must
behave correctly without one. Recovery is only necessary if other paths have
failed, so STR can be read by the host when it decides recovery is required,
and by read by time-based polling thereafter.

The host must be prepared to handle LPC SYNC errors when accessing the KCS
device IO addresses, particularly "No Response" aborts. It is not guaranteed
that the KCS device will remain available during BMC resets.

As STR is polled by the host it's not necessary for the BMC to write to ODR.
The protocol only requires the host to write to IDR and periodically poll STR
for changes to IBF and Ready state. This removes bi-directional dependencies.

The uni-directional writes and the lack of SerIRQ reduce the features required
for correct operation of the protocol and thus the surface area for failure of
the recovery protocol.

The layout of the KCS Status Register (STR) is as follows:

| Bit | Owner    | Definition               |
|-----|----------|--------------------------|
| 7   | Software |                          |
| 6   | Software |                          |
| 5   | Software |                          |
| 4   | Software | Ready                    |
| 3   | Hardware | Command / Data           |
| 2   | Software |                          |
| 1   | Hardware | Input Buffer Full (IBF)  |
| 0   | Hardware | Output Buffer Full (OBF) |

### A Real-World Implementation of the KCS Protocol for Power10 Platforms

Implementing the protocol described above in userspace is challenging due to
available kernel interfaces[1], and implementing the behaviour in the kernel
falls afoul of the defacto "mechanism, not policy" rule of kernel support.

Realistically, on the host side the only requirements are the use of a timer
and writing the appropriate value to the Input Data Register (IDR). All the
proposed status bits can be ignored. With this in mind, the BMC's
implementation can be reduced to reading an appropriate value from IDR.
Reducing requirements on the BMC's behaviour in this way allows the use of the
`serio_raw` driver (which has the restriction that userspace can't access the
status value).

[1] https://lore.kernel.org/lkml/37e75b07-a5c6-422f-84b3-54f2bea0b917@www.fastmail.com/

### Prototype Implementation Supporting Power10 Platforms

A concrete implementation of the proposal's userspace daemon is available on
Github:

https://github.com/amboar/debug-trigger/

Deployment requires additional kernel support in the form of patches at [2].

[2] https://github.com/amboar/linux/compare/2dbb5aeba6e55e2a97e150f8371ffc1cc4d18180...for/openbmc/kcs-raw

## Alternatives Considered

See the discussion in Background.

## Impacts

The proposal has some security implications. The mechanism provides an
unauthenticated means for the host firmware to crash and/or reboot the BMC,
which can itself become a concern for stability and availability. Use of this
feature requires that the host firmware is trusted, that is, that the host and
BMC firmware must be in the same trust domain. If a platform concept requires
that the BMC and host firmware remain in disjoint trust domains then this
feature must not be provided by the BMC.

As the feature might provide surprising system behaviour, there is an impact on
documentation for systems deploying this design: The mechanism must be
documented in such a way that rebooting the BMC in these circumstances isn't
surprising.

Developers are impacted in the sense that they may have access to better debug
data than might otherwise be possible. There are no obvious developer-specific
drawbacks.

Due to simplicity being a design-point of the proposal, there are no
significant API, performance or upgradability impacts.

## Testing

Generally, testing this feature requires complex interactions with
host firmware and platform-specific mechanisms for triggering the reboot
behaviour.

For Power10 platforms this feature may be safely tested under QEMU by scripting
the monitor to inject values on the appropriate KCS device. Implementing this
for automated testing may need explicit support in CI.