cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

einj.rst (8391B)


      1.. SPDX-License-Identifier: GPL-2.0
      2
      3====================
      4APEI Error INJection
      5====================
      6
      7EINJ provides a hardware error injection mechanism. It is very useful
      8for debugging and testing APEI and RAS features in general.
      9
     10You need to check whether your BIOS supports EINJ first. For that, look
     11for early boot messages similar to this one::
     12
     13  ACPI: EINJ 0x000000007370A000 000150 (v01 INTEL           00000001 INTL 00000001)
     14
     15which shows that the BIOS is exposing an EINJ table - it is the
     16mechanism through which the injection is done.
     17
     18Alternatively, look in /sys/firmware/acpi/tables for an "EINJ" file,
     19which is a different representation of the same thing.
     20
     21It doesn't necessarily mean that EINJ is not supported if those above
     22don't exist: before you give up, go into BIOS setup to see if the BIOS
     23has an option to enable error injection. Look for something called WHEA
     24or similar. Often, you need to enable an ACPI5 support option prior, in
     25order to see the APEI,EINJ,... functionality supported and exposed by
     26the BIOS menu.
     27
     28To use EINJ, make sure the following are options enabled in your kernel
     29configuration::
     30
     31  CONFIG_DEBUG_FS
     32  CONFIG_ACPI_APEI
     33  CONFIG_ACPI_APEI_EINJ
     34
     35The EINJ user interface is in <debugfs mount point>/apei/einj.
     36
     37The following files belong to it:
     38
     39- available_error_type
     40
     41  This file shows which error types are supported:
     42
     43  ================  ===================================
     44  Error Type Value	Error Description
     45  ================  ===================================
     46  0x00000001        Processor Correctable
     47  0x00000002        Processor Uncorrectable non-fatal
     48  0x00000004        Processor Uncorrectable fatal
     49  0x00000008        Memory Correctable
     50  0x00000010        Memory Uncorrectable non-fatal
     51  0x00000020        Memory Uncorrectable fatal
     52  0x00000040        PCI Express Correctable
     53  0x00000080        PCI Express Uncorrectable non-fatal
     54  0x00000100        PCI Express Uncorrectable fatal
     55  0x00000200        Platform Correctable
     56  0x00000400        Platform Uncorrectable non-fatal
     57  0x00000800        Platform Uncorrectable fatal
     58  ================  ===================================
     59
     60  The format of the file contents are as above, except present are only
     61  the available error types.
     62
     63- error_type
     64
     65  Set the value of the error type being injected. Possible error types
     66  are defined in the file available_error_type above.
     67
     68- error_inject
     69
     70  Write any integer to this file to trigger the error injection. Make
     71  sure you have specified all necessary error parameters, i.e. this
     72  write should be the last step when injecting errors.
     73
     74- flags
     75
     76  Present for kernel versions 3.13 and above. Used to specify which
     77  of param{1..4} are valid and should be used by the firmware during
     78  injection. Value is a bitmask as specified in ACPI5.0 spec for the
     79  SET_ERROR_TYPE_WITH_ADDRESS data structure:
     80
     81    Bit 0
     82      Processor APIC field valid (see param3 below).
     83    Bit 1
     84      Memory address and mask valid (param1 and param2).
     85    Bit 2
     86      PCIe (seg,bus,dev,fn) valid (see param4 below).
     87
     88  If set to zero, legacy behavior is mimicked where the type of
     89  injection specifies just one bit set, and param1 is multiplexed.
     90
     91- param1
     92
     93  This file is used to set the first error parameter value. Its effect
     94  depends on the error type specified in error_type. For example, if
     95  error type is memory related type, the param1 should be a valid
     96  physical memory address. [Unless "flag" is set - see above]
     97
     98- param2
     99
    100  Same use as param1 above. For example, if error type is of memory
    101  related type, then param2 should be a physical memory address mask.
    102  Linux requires page or narrower granularity, say, 0xfffffffffffff000.
    103
    104- param3
    105
    106  Used when the 0x1 bit is set in "flags" to specify the APIC id
    107
    108- param4
    109  Used when the 0x4 bit is set in "flags" to specify target PCIe device
    110
    111- notrigger
    112
    113  The error injection mechanism is a two-step process. First inject the
    114  error, then perform some actions to trigger it. Setting "notrigger"
    115  to 1 skips the trigger phase, which *may* allow the user to cause the
    116  error in some other context by a simple access to the CPU, memory
    117  location, or device that is the target of the error injection. Whether
    118  this actually works depends on what operations the BIOS actually
    119  includes in the trigger phase.
    120
    121BIOS versions based on the ACPI 4.0 specification have limited options
    122in controlling where the errors are injected. Your BIOS may support an
    123extension (enabled with the param_extension=1 module parameter, or boot
    124command line einj.param_extension=1). This allows the address and mask
    125for memory injections to be specified by the param1 and param2 files in
    126apei/einj.
    127
    128BIOS versions based on the ACPI 5.0 specification have more control over
    129the target of the injection. For processor-related errors (type 0x1, 0x2
    130and 0x4), you can set flags to 0x3 (param3 for bit 0, and param1 and
    131param2 for bit 1) so that you have more information added to the error
    132signature being injected. The actual data passed is this::
    133
    134	memory_address = param1;
    135	memory_address_range = param2;
    136	apicid = param3;
    137	pcie_sbdf = param4;
    138
    139For memory errors (type 0x8, 0x10 and 0x20) the address is set using
    140param1 with a mask in param2 (0x0 is equivalent to all ones). For PCI
    141express errors (type 0x40, 0x80 and 0x100) the segment, bus, device and
    142function are specified using param1::
    143
    144         31     24 23    16 15    11 10      8  7        0
    145	+-------------------------------------------------+
    146	| segment |   bus  | device | function | reserved |
    147	+-------------------------------------------------+
    148
    149Anyway, you get the idea, if there's doubt just take a look at the code
    150in drivers/acpi/apei/einj.c.
    151
    152An ACPI 5.0 BIOS may also allow vendor-specific errors to be injected.
    153In this case a file named vendor will contain identifying information
    154from the BIOS that hopefully will allow an application wishing to use
    155the vendor-specific extension to tell that they are running on a BIOS
    156that supports it. All vendor extensions have the 0x80000000 bit set in
    157error_type. A file vendor_flags controls the interpretation of param1
    158and param2 (1 = PROCESSOR, 2 = MEMORY, 4 = PCI). See your BIOS vendor
    159documentation for details (and expect changes to this API if vendors
    160creativity in using this feature expands beyond our expectations).
    161
    162
    163An error injection example::
    164
    165  # cd /sys/kernel/debug/apei/einj
    166  # cat available_error_type		# See which errors can be injected
    167  0x00000002	Processor Uncorrectable non-fatal
    168  0x00000008	Memory Correctable
    169  0x00000010	Memory Uncorrectable non-fatal
    170  # echo 0x12345000 > param1		# Set memory address for injection
    171  # echo $((-1 << 12)) > param2		# Mask 0xfffffffffffff000 - anywhere in this page
    172  # echo 0x8 > error_type			# Choose correctable memory error
    173  # echo 1 > error_inject			# Inject now
    174
    175You should see something like this in dmesg::
    176
    177  [22715.830801] EDAC sbridge MC3: HANDLING MCE MEMORY ERROR
    178  [22715.834759] EDAC sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090
    179  [22715.834759] EDAC sbridge MC3: TSC 0
    180  [22715.834759] EDAC sbridge MC3: ADDR 12345000 EDAC sbridge MC3: MISC 144780c86
    181  [22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0
    182  [22716.616173] EDAC MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0 -  area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0)
    183
    184Special notes for injection into SGX enclaves:
    185
    186There may be a separate BIOS setup option to enable SGX injection.
    187
    188The injection process consists of setting some special memory controller
    189trigger that will inject the error on the next write to the target
    190address. But the h/w prevents any software outside of an SGX enclave
    191from accessing enclave pages (even BIOS SMM mode).
    192
    193The following sequence can be used:
    194  1) Determine physical address of enclave page
    195  2) Use "notrigger=1" mode to inject (this will setup
    196     the injection address, but will not actually inject)
    197  3) Enter the enclave
    198  4) Store data to the virtual address matching physical address from step 1
    199  5) Execute CLFLUSH for that virtual address
    200  6) Spin delay for 250ms
    201  7) Read from the virtual address. This will trigger the error
    202
    203For more information about EINJ, please refer to ACPI specification
    204version 4.0, section 17.5 and ACPI 5.0, section 18.6.