On 18.10.23 11:00, Michael Adler wrote:
> Hi Jan,
>
>> This looks fishy: We are now adding a partition in read_GPT_entries to
>> the list which is NOT a FAT partition. Why should that be correct?
>
> it looks fishy because it's not so obvious what's actually going on. It took
> me a while to understand the "grand scheme of things", so here is a brief
> summary:
>
> 1. `check_GPT_FAT_entry` does more than just checking the FAT entry, it
> actually writes a string (fatXX) to one of its arguments (pfst->name) if it
> was able to determine the FAT partition type.
>
> 2. The return value of `check_GPT_FAT_entry` is a boolean indicating success.
> If the return value is false (i.e. error), then `dev->part_list` is set to
> NULL. The consequence is that *every* partition of the underlying device is
> skipped. In other words, a single bad partition results in the whole device
> being ignored.
>
> 3. Whether we probe (i.e. mount) a partition and check for BGENV.DAT depends
> on the string value pfst->name which is written in step 1), see
> `probe_config_partitions`.
>
Oookay... Then how about fixing this in code in a way that it no longer
needs such out-of-band documentation?
char *get_partition_type(int fd, struct EFIpartitionentry *e,
uint32_t partnum)
Would return the type name in a malloc'ed string or NULL on error. Maybe
there are even better ideas.
Jan
--
Siemens AG, Technology
Linux Expert Center
--
You received this message because you are subscribed to the Google Groups "EFI
Boot Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/efibootguard-dev/91b41495-b958-43e2-b252-467ac712db5d%40siemens.com.
