-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix file system browser hang when enrolling MOK from disk #622
base: main
Are you sure you want to change the base?
Conversation
The loop retrieving the SimpleFS volume labels and names may skip some volumes if either HandleProtocol or OpenVolume or GetInfo fails. Those skipped volumes would have uninitialized pointers to their names in the respective entries indices. This would lead to accessing random memory in console_select, because count_lines would not catch the holes with non-existing entries. On affected platforms the result is a hang of the MokManager while trying to enroll a key from disk. The issue has been triggered on a TianoCore EDK2 UEFIPayload based firmware for x86 platforms with additional filesystem drivers: ExFAT, NTFS, EXT2 and EXT4. Use AllocateZeroPool to ensure entries array will be initialized with NULL pointers. Handling the non-existing entries will be added in subsequent commits. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
In case GetInfo of volume root fails, it is still possible to form a volume name from the DevicePath. Do not skip given SimpleFS volume handle and try to form a name from DevicePath. That way we do not lose some filesystems from file browser. This change already fixes the problem of a hanging platform when trying to enroll a key from disk. However, there is still a chance of having a non-contiguous array of entries, which will be fixed in next commit. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
If HandleProtocol or OpenVolume fails, the entries array will become non-contiguous, i.e. will have NULL pointers between valid volume names in the array. Because of that count_lines may return a lower number of entries than expected. As a result one may not browse all valid filesystems in the file explorer. Add a second index variable that will increment only on successfully created filesystem entries. As a result, count_lines should return proper length and there won't be any lost partitions or accesses to invalid entries. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
This looks fairly reasonable to me, but what I don't understand is this: what are the failures? How are they triggered, and under what conditions? |
The FS drivers mentioned in my first comment did not necessarily implement The second problem is the multiple tl;dr
Before my PR the result would be:
|
Basically I have made the code more robust accounting for minimal FS driver implementations and avoiding possible access to random memory. Also the |
I have encountered this exact issue on PRO Z790-P WIFI (MS-7E06) running Dasharo (coreboot+UEFI) v0.9.1 with disk where the only non-encrypted partition is EFI System Partition. |
@vathpela have I made it more clear possibly? |
@vathpela ping |
Anything I can do to help this PR land @vathpela ? |
@miczyg1, maybe we can bring this topic to the Linux Plumbers Conference? |
The loop retrieving the SimpleFS volume labels and names may skip some volumes if either HandleProtocol or OpenVolume or GetInfo fails. Those skipped volumes would have uninitialized pointers to their names in the respective entries indices. This would lead to accessing random memory in console_select, because count_lines would not catch the holes with non-existing entries.
On affected platforms the result is a hang of the MokManager while trying to enroll a key from disk. The issue has been triggered on a TianoCore EDK2 UEFIPayload based firmware for x86 platforms with additional filesystem drivers: ExFAT, NTFS, EXT2 and EXT4.