On 2024-03-14 09:16, Jan Beulich wrote:
On 13.03.2024 20:30, Jason Andryuk wrote:
@@ -217,6 +225,15 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
      case XEN_ELFNOTE_PHYS32_ENTRY:
          parms->phys_entry = val;
          break;
+
+    case XEN_ELFNOTE_L1_MFN_VALID:
+        if ( elf_uval(elf, note, descsz) != 2 * sizeof(uint64_t) )
+            return -1;

elf_note_numeric() use sites don't have such a check. Why would we need
one here, and even more so causing a error to be raised when in reality
the supplied values (still) aren't consumed? Furthermore the documentation
says "pairs" (plural) for a reason. Finally maddr_t-sized only happens to
mean uint64_t on all architectures we presently support.

I failed to pay attention to the definition stating plural pairs. I saw Linux stored two 64bit values and printed them.

I added the size check to avoid going out of bounds. elf_note_numeric() handles 1, 2, 4 or 8 bytes and returns 0 otherwise, so it won't overrun boundaries. That's why it was getting printed as "ELF: note: L1_MFN_VALID = 0"

What motivated this was seeing "PVH_RELOCATION = 0". That confusingly looks like relocation is disabled.

I'm fine dropping this attempt at printing the L1_MFN_VALID note. maddr_t is not defined, and it looks the note values were 32bit in non-PAE kernels. It could just be printed as "ELF: note: L1_MFN_VALID" with no details.

Regards,
Jason

+        elf_msg(elf, "mask: %#"PRIx64" val: %#"PRIx64"\n",
+                elf_note_numeric_array(elf, note, 8, 0),
+                elf_note_numeric_array(elf, note, 8, 1));
+        break;
      }
      return 0;
  }


Reply via email to