8455 Simple post-mortem reporter for amd64 loader.efi

Review Request #612 — Created July 4, 2017 and submitted


ok grab_faults
ok fault
Exception 6
ss 0x0008 cs 0x0018 ds 0x0008 es 0x0008 fs 0x0008 gs 0x0008
err 0x00000000 rfl 0x00210246 addr 0x0000000000000000
rsp 0x000000000ffd92a8 rip 0x000000000a6f3da0
rdi 0x0000000000000001 rsi 0x00000000066e00d0 rdx 0x00000000066e0080
rcx 0x00000000066e0160 r8 0x00000000066e00c0 r9 0x000000000a745430
rax 0x0000000000000000 rbx 0x00000000089f5ce0 rbp 0x000000000ffd9300
r10 0x000000006c756166 r11 0x00000000000003f8 r12 0x00000000066e0040
r13 0x0000000000000064 r14 0x000000000a746250 r15 0x000000000a6f3da0
Machine stopped.

and with faulty code:
Exception 13
ss 0x0008 cs 0x0018 ds 0x0008 es 0x0008 fs 0x0008 gs 0x0008
err 0x00000000 rfl 0x00210206 addr 0x0000000000000000
rsp 0x000000000ffd9148 rip 0x000000000a721705
rdi 0x8e292d5f288fb843 rsi 0x000000000902b040 rdx 0x00000000288fb843
rcx 0x00000000d88e4f04 r8 0x000000001ac0d4ad r9 0x000000005d21a5e3
rax 0x00000000000001bf rbx 0x8e292d5f288fb843 rbp 0x98b82a678ecacd1c
r10 0x00000000249b79ca r11 0x00000000668cdcff r12 0x000000005a3585a9
r13 0x0000000000000040 r14 0x000000000902aec0 r15 0x00000000000001c0
Machine stopped.

  • 0
  • 0
  • 0
  • 4
  • 4
Description From Last Updated
  2. In illumos we have a different definition of what these bits are:

    320 uint64_t ssd_avl:1; /* available to sw, but not used */
    321 uint64_t ssd_resv1:2; /* unused, ignored */

    That's from sys/segments.h struct system_desc. Not sure if it it's useful or not.

  3. Do you know how the exc_rsp value is being populated for doing this comparison? This feels related to the macro logic at +34, but it's not quite clear to me how it's supposed to fit together.
    1. The population is done in trap.c with PREPARE_EXCEPTION() macro in efi_redirect_exceptions(), but the handler codes are generated by EH macro.

  4. Any reason we have this forward?
    1. FreeBSD has -Wmissing-prototypes enabled by default (with clang), gcc does complain in a same way (if enabled).

    2. Do you know why the compiler complains about it? I guess I just saw it weird to have the prototype immediately before the function. Did I miss a recursive call or something else in there?
  5. Do you know why this is an XXX?
    1. kib: printf depends on large parts of the loader runtime health to work
      kib: while exception means that it is not

      Which of course means that the printf itself can fail there, but we do not have much to do about it because the console output also depends on UEFI boot services.

    2. This makes sense, but could you please make this a comment? XXX using printf doesn't really tell much.

  6. Do you know why this is an XXX?
    1. kib: I reuse uefi selector for the code segment
      kib: for the exception handler code
      kib: while the reason for the fault might be the corruption of that gdt entry
      kib: on the other hand, allocating my own descriptor might be not much better, if gdt is corrupted at all
      kib: so this is something to remember, but I do not see how to make it more reliable
      kib: except to run the loader and uefi code under vmm monitor

    2. Same, could you please make this a description a comment replacing XXX, which doesn't really tell me anyhing?

  1. Ship It!
Review request changed

Status: Closed (submitted)