Re: compatability with older versions of UEFI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Another option would be to have 2 structs, the first one
"struct cper_sec_mem_err" holds the structure as defined by UEFI
2.1, the 2nd one "struct cper_sec_mem_err_24_ext" holds the 4
elements added in UEFI 2.3.1.

In the past how is such situation (newer version of spec adds elements
to existing table) handled? To me, the "extension structure" option
proposed above makes sense because it allows rigid check of data
passed from firmware to OS.

Jonathan

On 6/23/2015 10:05 AM, Luck, Tony wrote:
When we print UEFI appendix N error logs provided by plaform
firmware we get to this function:

static void cper_estatus_print_section(
	const char *pfx, const struct acpi_hest_generic_data *gdata, int sec_no)
{

Which includes this code (similar for the other section types):


	} else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
		struct cper_sec_mem_err *mem_err = (void *)(gdata + 1);
		printk("%s""section_type: memory error\n", newpfx);
		if (gdata->error_data_length >= sizeof(*mem_err))
			cper_print_mem(newpfx, mem_err);
		else
			goto err_section_too_small;

I'm having a problem with that size check.  The kernel defines
"struct cper_sec_mem_err" according to the 2.3.1 and later versions
of the spec where the last element is the module handle at offset 78
so the "sizeof(*mem_err)" is 80.  But my BIOS defaults to providing
version 2.2 format information, where the last field is the memory
error type, and the struture size is only 73 bytes. So this code
takes the goto err_section_too_small, prints an error message, and
stops decoding.

This is a pity because it looks like the UEFI folk took great care
to make these structures back/forward compatible. Each has a bitfield
at the start saying which elements are valid ... so my 2.2 using BIOS
will never set the valid bits for the fields it doesn't know about.

Perhaps we can have some defines for the size of these structures
in the oldest version of the spec where they exist (2.1 AFAICT):

#define	UEFI_MEMSECTION_MIN_SIZE	73

etc. Then use these as the sanity check?

Or we can be totally distrustful of the BIOS and pass the
"gdata->error_data_length" to the print function and have
it check that size against the offset of any fields that
the validation_bits say we should print.  This feels like
overkill.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux